GlobaLeaks fails to respond after upgrade + reverse proxy setup (stuck spinner / 502)

[compliance-lat]

Prerequisites

• I have read the contributing guidelines
• I have searched existing issues for duplicates or prior discussions
• I have attempted to reproduce the issue on try.globaleaks.org

What version of GlobaLeaks are you using?

5.0.72

On which distribution/version is GlobaLeaks installed?

debian-11-bullseye-v20230206

What browser(s) are you seeing the problem on?

No response

What operating system(s) are you seeing the problem on?

Linux

Describe the issue

❗ GlobaLeaks fails to respond after upgrade + reverse proxy setup (stuck spinner / 502)

Background

Our GlobaLeaks instance was working perfectly before introducing Nginx. It was running standalone on version 4.10.18, and fully functional over the default HTTPS configuration provided by GlobaLeaks. The public domain https://canal.compliance.lat pointed directly to the service via port 8443.

After upgrading (via the official installation script), we lost access. The browser shows an infinite spinner, and network tools indicate that the backend fails to respond consistently. This upgrade attempt was combined with the configuration of a reverse proxy using Nginx — which is now in place.

---

Hypothesis

We suspect a combination of two issues:

• The upgrade moved us beyond version 4.10.18 to a newer GlobaLeaks version with significant changes.
• Some keys, tokens, or compatibility features in our persisted configuration became deprecated or invalid, silently breaking the backend.
• At the same time, Nginx may be misconfigured or expecting a backend response format that is no longer valid or reachable.

---

Environment Summary

Component	Value
OS	Debian GNU/Linux 11 (Bullseye)
Python	3.9.2
GlobaLeaks	Newest available (via script), upgraded from 4.10.18
Install Method	install-globaleaks.sh
Domain	https://canal.compliance.lat
Public IP	34.176.234.78
Hosting	Google Cloud VM
TLS	Previously handled by GlobaLeaks directly; now via Nginx proxy

---

✅ What Works

• GlobaLeaks starts via systemctl start globaleaks without crash.
• Logs show:

  GlobaLeaks is now running and accessible at:
  - [HTTPS]: https://canal.compliance.lat
  

• TCP ports 8080 (http), 8083 (internal?), and 8443 (https) are listening.
• iptables allows traffic to 8080 and 8443.
• Domain resolves and responds to ping.

---

❌ What Fails

• The frontend at https://canal.compliance.lat shows only a loading spinner.
• Chrome developer tools report:
  • ERR_CONNECTION_REFUSED for requests to /api/public
  • CSP/TrustedTypes violations (e.g., goog#html disallowed)
• Curl results:

  curl -I http://127.0.0.1:8080      # → Connection refused
  curl -I https://127.0.0.1:8080     # → Connection refused

• Nginx returns: 502 Bad Gateway.
• systemctl status globaleaks shows the process starts and then becomes inactive (dead).
• Systemd logs include:

  PermissionError: [Errno 13] Permission denied: '.'
  

  (unless WorkingDirectory is set manually in the unit file)

---

🔧 Nginx Proxy Snippet

server {
    listen 80 default_server;
    server_name canal.compliance.lat;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Proposed solution

❓ Questions

1. Could old persisted configuration (DB, keys, state) from 4.10.18 be incompatible with the current version?
2. Is there a specific port (8443 or 8080) we should proxy to post-upgrade?
3. What is the correct WorkingDirectory for the globaleaks.service systemd unit?
4. Is there a known issue related to the /api/public endpoint or frontend boot after upgrade?

---

🧩 Conclusion

This issue appeared right after upgrading a stable and working GlobaLeaks 4.10.18 install.

We seek guidance on whether:

• We should start fresh with a clean install?
• There's a known migration path or compatibility layer?
• Or if we should modify the proxy or config to accommodate changes in the GlobaLeaks backend?

Let us know what logs or diagnostics would help. We're happy to provide full trace, environment variables, or config files if needed.

[evilaliv3]

Thank you for your question @compliance-lat

As stated into the documentation globaleaks is designed to be run without proxy intermediaries that within the threat model are considered as a threat and their use is discouraged: https://docs.globaleaks.org/en/stable/security/ThreatModel.html#network-and-reverse-proxies

To resolve the issue we suggest to expose globaleaks publicly without any intermediate proxies