Connection to the server has failed when self-hosting using docker quick start

Android63 · January 18, 2023, 2:44pm

Following the quick start guide I executed the following command on my laptop:

docker run \
  -d \
  --name baserow \
  -e BASEROW_PUBLIC_URL=http://localhost:3001 \
  -v baserow_data:/baserow/data \
  -p 3001:80 \
  -p 443:443 \
  --restart unless-stopped \
  baserow/baserow:1.13.3

This launched Baserow successfully and I was able to access the dashboard at http://localhost:3001/dashboard.
However I keep getting the following error message:

Failed
Connection to the server has failed. Please refresh the page.

Looking at the console I see:

WebSocket connection to 'ws://localhost:3001/ws/core/?jwt_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ0b2tlbl90eXBlIjoiYWNjZXNzIiwiZXhwIjoxNjc0MDUzNDg4LCJpYXQiOjE2NzQwNTI4ODgsImp0aSI6IjM5ZWZlNGQ2Y2IzNTQ4YmZhZTI4ZDI3NjQ4OGVhMGViIiwidXNlcl9pZCI6MX0.8B9WuTYZLhaIo5y35T_rQefeNCx0c2S2fikkjG34z-M' failed:

Any advice please?

nigel · January 18, 2023, 3:48pm

@Android63 do you perhaps any plugins that might be blocking this websocket connection? Could you try in private/igcognito mode in your Browser and see if it works then?

This error is indicating that the websocket connection used for realtime events isn’t working.

Android63 · January 19, 2023, 11:10am

Thanks @nigel. It works fine in an incognito window as you suggested.

I have a few active browser plugins. I’ve tried disabling the most obvious ones (e.g. ad blocker) but can’t find out which one is causing the problem. Any suggestions on that?

nigel · January 19, 2023, 11:15am

No worries, could you tell me which browser + operating system you are using and the full list of plugins you have? If you want to keep it private feel free to PM me or email them to me at nigel@baserow.io .

Thanks

Android63 · January 19, 2023, 11:31am

I was using Google Chrome beta version 110.0.5481.38 (Official Build) beta (x86_64) running on macOS v12.6.

I say “was” because I’ve just switched to Chrome 109.0.5414.87 (Official Build) (x86_64) and it’s fine there.

I tried disabling all my plugins in Chrome beta but that didn’t work. Switching to the official Chrome build did the trick though.

Thanks for your speedy help and advise @nigel.

fanhkg · September 12, 2023, 7:16am

It might not be a Chrome plugin issue but a cookie-related issue.

This matter has also happened to me and cost me 5 hours to find out the reason. I set up my Baserow using Docker with Caddy + Nginx (with reverse proxy).

The 400 error code came from the Docker (using docker logs container_id) instead of from Nginx. Also I noticed that when I cleared my browser cookies, it has no issues; when I visited a couple of different pages and accumulated a lot of cookies, the issue reproduces. Therefore, the issue is: the cookie header is too large > http connection upgrade failed at handshake.

To solve this issue, simply remove all cookies for WS connections in Nginx using “proxy_hide_header Cookie”, “add_header Cookie”, and “proxy_set_header Cookie”. Below are my settings in Nginx:

    location ~ ^/api/ {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_pass http://127.0.0.1:1080;
    }
    location ~ ^/ws/ {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_hide_header Cookie;
        add_header Cookie "";
        proxy_set_header Cookie "";
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_pass http://127.0.0.1:1080;
    }

nigel · September 12, 2023, 8:01am

Glad you got it sorted, for future readers we have a guide on how to configure NGinx/Apache sitting in front of Baserow here: Installing Baserow behind Nginx // Baserow and Installing Baserow behind Apache // Baserow here.

fanhkg · September 12, 2023, 2:48pm

This is a fairly tricky issue related to Websocket connection upgrade (header size limited > websocket_upgrade_failure error). I wonder if there’s any way to increase that number with the docker config (instead of removing the cookie through Nginx)?

nigel · September 12, 2023, 3:02pm

Ah I apologize i see what you mean now, do you know which specific cookies were getting large as you visited different pages? And to double check, you are using the baserow/baserow image?

fanhkg · September 12, 2023, 4:23pm

It is not a specific cookie - but all the Websocket requests will include all the available cookies in the header. If you have a lot of cookies associated with the site (including cookies for the root domain, which is accessible by all subdomains), this issue will happen.

My site has many services, and all the cookies are under the root domain (which is not a good practice, I know…). I think that’s also the reason why some other people encountered the situation and (1) can see it work properly in the Incognito mode (2) couldn’t fix it in the normal mode even after disabling all the extensions - since this is not any issue with the extensions (some people suggested AdBlock extension may cause similar issues - not my case).

This issue could happen to some people who use Baserow to build an internal site with a subdomain, which shares cookie from the root domain.

I used the Docker-composer method to install Baserow with Caddy and then put that behind my own Nginx server - all following the official instructions (including the Nginx configs).

dev-rd · August 28, 2024, 6:36pm

Hi,

it seems that me and other people on my team experience this issue as well.

We seem to have a similar setup to the one described here (debian+ baserow docker image behind Nginx - I’m told - configured according to the guide linked in this thread. + a subdomain)

A few people on my team reported severe issues with filters and sorting not working properly (like filters missing certain fields, or sorting by wrong value, etc). I was able to reproduce some of these issues only when the “Connection to the server has failed. Please refresh the page.” error appeared.

The erros start to happen when scrolling the table, which seems to refresh the row values despite the seemingly lost connection, but the rest of the page (including filters) seems to stay “disconnected” until the entire browser tab is refreshed (hope the description makes sense).

I assume such errors could actually be expected under the circumstances… however, some people claim they have not seen the “Connection to the server has failed” error message, but a page refresh seem to have solved the issues for them - at least until they experienced them again at a different time.

My questions would be

is the fix proposed by @fanhkg is “officially supported” or in any way verified?
can the connection fail without the error message (which would explain many of the issues reported for filters by my team)

brauliodiasribeiro · February 21, 2025, 8:08am

If you use nginx webUI mode, just enable websokets support.