Replies: 10 comments
-
|
Hi @fengluo2! I'm Dosu and I’m helping the Trilium team. The most common cause of browser WebSocket connection failures with Trilium behind a reverse proxy is missing WebSocket upgrade headers in your proxy configuration. Tools like wscat can connect because they bypass browser restrictions, but browsers require the proxy to forward specific headers for WebSocket handshakes to work over HTTPS. For Caddy, your Caddyfile should include: example.com {
reverse_proxy http://trilium:8080 {
header_up Host {host}
header_up X-Forwarded-Proto {scheme}
header_up Upgrade {http.upgrade}
header_up Connection {http.connection}
}
}For Nginx, use: proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;If you use Apache, enable the After updating your proxy config, reload the proxy and clear your browser cache. If it still fails, check your proxy logs for errors during the WebSocket handshake and confirm Docker networking allows the proxy to reach Trilium. More details and examples are in this issue and this comment. If you share your proxy config, I can help review it for any missing settings. To reply, just mention @dosu. How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other |
Beta Was this translation helpful? Give feedback.
-
|
A successful local test should mean the reverse proxy configuration is working correctly, right? @dosu |
Beta Was this translation helpful? Give feedback.
-
|
Not necessarily—wscat can connect even if the reverse proxy isn’t fully set up for browsers. Browsers have stricter requirements: your proxy must forward specific headers (like If you want to double-check, review your proxy config for those headers, confirm To reply, just mention @dosu. How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Your OpenResty config includes the right headers for WebSocket support, and trustedReverseProxy is set in Trilium, which are both required for browser WebSocket connections. One thing to double-check: your proxy_pass points to http://127.0.0.1:8081, but Trilium’s default port is 8080—make sure Trilium is actually running on 8081, or update either the proxy or Trilium’s config.ini so the ports match. A mismatch here will cause connection failures even if everything else is correct. If the ports are aligned, try clearing your browser cache and cookies, then reload. If it still fails, check both OpenResty and Trilium logs for errors during the WebSocket handshake—look for upgrade or authentication/session issues. Sometimes, browser cache or HSTS can cause persistent failures even after fixing the proxy config. If you’re still stuck after these checks, let me know what you see in the logs or if there are any error messages in the browser’s network tab. To reply, just mention @dosu. How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other |
Beta Was this translation helpful? Give feedback.
-
|
The problem persists even after changing it to 8081. |
Beta Was this translation helpful? Give feedback.
-
|
Your setup and headers look correct, but when wscat works and browsers don't, it's almost always a subtle proxy or session issue. Browsers require the proxy to forward Upgrade and Connection headers exactly as expected, and sometimes CLI tools succeed even if the proxy isn't forwarding them perfectly for browsers. This is a common problem with reverse proxies and Trilium—see similar cases and solutions here and here. Here’s what to try next:
If the browser’s network tab shows the WebSocket handshake never reaches the backend (no 101 Switching Protocols), the proxy is still not forwarding the upgrade request correctly—even if the config looks right. Double-check for typos or extra whitespace in your OpenResty config, and try temporarily removing extra headers to isolate the issue. If you can share the browser’s network error details or a screenshot of the failed WebSocket request, I can help pinpoint the problem further. To reply, just mention @dosu. How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other |
Beta Was this translation helpful? Give feedback.
-
|
I tried enabling HTTPS directly in the configuration file, and WSS worked fine. However, the same problem occurred when using a reverse proxy (wss->wss). It seems to be a reverse proxy issue. I'll try modifying the reverse proxy configuration again. This issue can be closed now. |
Beta Was this translation helpful? Give feedback.
-
|
This is my complete configuration. You can try it out using nginx + docker to see if it can proxy properly. I don't plan to use a proxy anymore; I'll just use the built-in SSL certificate. |
Beta Was this translation helpful? Give feedback.
-
|
I have the same problem. I deployed Trilium using Docker and then used Traefik as a reverse proxy. I found that the web version has issues, showing a message that the websocket has been disconnected. |
Beta Was this translation helpful? Give feedback.


Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Description
The system uses Docker and a reverse proxy
Locally, wscat can connect and receive ping messages
however, the browser indicates a connection failure
TriliumNext Version
0.99.3
What operating system are you using?
Ubuntu
What is your setup?
Server access only
Operating System Version
ubuntu24
Error logs
There were no obvious error messages; the browser console was just constantly trying to reconnect.
Beta Was this translation helpful? Give feedback.
All reactions