Trilium Next
-
DescriptionHello, I am having an issue with the synchronisation from my mac. I get the error ERROR: Failed to deserialize sync response as the answer seems to be a fallback page in html and not a json response. When I get to the url on the browser or via curl, on the same machine, I get the correct JSON This is an enterprise mac and I do have some forticlient with EDR and content filtering enabled. My guess was that it was the cause of the issue, however the network team assures me that they don't see anything being blocked and that it should work fine. We tried with having it disabled temporarily but that didn't work. As the curl works, I am writing this issue as it seems that maybe the mac application could have an issue ? If you could help me solve this, it would be greatly appreciated Best regards, TriliumNext Version0.98.1 What operating system are you using?macOS What is your setup?Local + server sync Operating System VersionmacOS Sequoia 15.6.1 Error logs |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 1 reply
-
|
Hi @Llyr95! I'm Dosu and I’m helping the Trilium team. This error almost always points to a misconfiguration in the nginx reverse proxy, not a bug in Trilium itself. The Trilium desktop app (Electron client) sends sync requests using Node.js HTTP libraries, which can set a different user-agent and headers than curl or a browser—this sometimes triggers different behavior from nginx or security appliances, especially on enterprise-managed Macs with EDR/content filtering. When nginx or a proxy serves an HTML fallback page instead of JSON, it usually means the request isn't reaching the Trilium API handler as intended, often due to missing or misconfigured proxy headers or location blocks reference. Double-check your nginx config against the official example: make sure headers like Compare the request headers/user-agent from the Trilium app and curl (you can use a tool like Wireshark or a proxy to capture them). Sometimes, proxies or security appliances treat Electron apps differently. Also, check nginx and Trilium logs for errors when the sync fails—this often reveals whether the request is being redirected, blocked, or mishandled. If you have OIDC or other authentication on the proxy, note that Trilium desktop sync does not support OIDC and will fail if it receives an HTML login page instead of JSON reference. In summary: review your nginx config, compare headers, and check logs. The issue is almost certainly with the proxy setup or a network appliance treating the Electron app differently than curl/browser. To reply, just mention @dosu. How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other |
Beta Was this translation helpful? Give feedback.
-
|
@dosu is right. What is happening here is that the sync process is expecting to reach the API endpoint (which uses JSON under the hood), however it receives an HTML page titled "Welcome to our server". You have to identify where that page comes from. |
Beta Was this translation helpful? Give feedback.
-
|
The "Welcome to our server" HTML page is almost certainly coming from your nginx reverse proxy as a default or fallback page when the sync API request from the Trilium app isn't routed to the backend correctly. This usually happens due to a misconfiguration in nginx—such as missing or incorrect proxy_pass, headers, or location blocks. The Trilium desktop app (Electron) can send different headers or user-agent than curl or a browser, which sometimes triggers different proxy or security appliance behavior, especially on enterprise-managed Macs with EDR/content filtering enabled. Double-check your nginx config against the official example: make sure headers like Host, X-Real-IP, X-Forwarded-For, X-Forwarded-Proto, Upgrade, and Connection are set, and proxy_pass points to the correct backend. Also, set client_max_body_size 0; in your server block to avoid payload size issues. If you’re using a reverse proxy for TLS termination, add the trustedReverseProxy setting in Trilium’s config.ini with your proxy’s IP. Comparing request headers/user-agent from the Trilium app and curl (using Wireshark or a proxy) can help spot differences. Check nginx and Trilium logs for errors when the sync fails—this often reveals whether the request is being redirected, blocked, or mishandled. If you use OIDC or other authentication on the proxy, note that Trilium desktop sync does not support OIDC and will fail if it receives an HTML login page instead of JSON reference. To reply, just mention @dosu. How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other |
Beta Was this translation helpful? Give feedback.
Hi @Llyr95! I'm Dosu and I’m helping the Trilium team.
This error almost always points to a misconfiguration in the nginx reverse proxy, not a bug in Trilium itself. The Trilium desktop app (Electron client) sends sync requests using Node.js HTTP libraries, which can set a different user-agent and headers than curl or a browser—this sometimes triggers different behavior from nginx or security appliances, especially on enterprise-managed Macs with EDR/content filtering. When nginx or a proxy serves an HTML fallback page instead of JSON, it usually means the request isn't reaching the Trilium API handler as intended, often due to missing or misconfigured proxy headers or location blocks re…