devlup-labs / devlup-labs/CIPHER
[BUG] : Relay server fails WSS connections behind reverse proxy
- Dominant language
- Go
- Stars
- 3
- Forks
- 8
- PR merge metrics
- No merged PRs in 30d
Description
**Describe the bug**
When deploying the relay server to Render (or any platform behind a reverse proxy that terminates TLS), libp2p clients fail to connect to the relay using the WSS (WebSocket Secure) protocol. The connection is rejected with a `websocket: bad handshake` error.
This happens because the relay server is only listening on raw TCP/QUIC ports and does not have a `/ws` WebSocket listener configured in its multiaddresses. When Render terminates the `wss://` connection and forwards it as `ws://` traffic, the libp2p node fails to process the HTTP upgrade request.
**To Reproduce**
Steps to reproduce the behavior:
1. Deploy the `Relay-Torrentium` service to Render as a Web Service.
2. Attempt to connect to the relay from a client using a WSS multiaddr, for example:
```bash
go run ./cmd/client -provider /dns4/your-render-app.onrender.com/tcp/443/wss/p2p//...
```
3. See error output:
```diff
- Failed to connect to provider error="failed to dial: ...
- * [/ip4/216.24.57.8/tcp/443/tls/sni/your-render-app.onrender.com/ws] websocket: bad handshake
```
**Expected behavior**
The relay server should successfully accept the WebSocket upgrade and allow clients to connect via WSS behind the reverse proxy.
**Logs**
```diff
user@machine CIPHER % go run ./cmd/client -provider /dns4/relay-torrentium-3zok.onrender.com/tcp/443/wss/p2p/12D3KooWEBxhvkASAJtmdeKWiWWhdXCzwXEVvSMpjuY8YrDAi68Z/p2p-circuit/ip4/192.168.29.200/tcp/9000/p2p/12D3KooWRuNNvk5MKMfH94VV5PwxUyYjPHTLvT1MrkmpEvD55nxK -root 4c5f04eddf968f7df7f75282541b784e48f4bae5516fc9413738bf4888e76129 -chunks 4
2026-07-15T23:42:36+05:30 INF mDNS discovery enabled
- 2026-07-15T23:42:37+05:30 FTL Failed to connect to provider error="failed to dial: failed to dial 12D3KooWRuNNvk5MKMfH94VV5PwxUyYjPHTLvT1MrkmpEvD55nxK: all dials failed\n * [/dns4/relay-torrentium-3zok.onrender.com/tcp/443/wss/p2p/12D3KooWEBxhvkASAJtmdeKWiWWhdXCzwXEVvSMpjuY8YrDAi68Z/p2p-circuit/ip4/192.168.29.200/tcp/9000] error opening hop stream to relay: failed to dial: failed to dial 12D3KooWEBxhvkASAJtmdeKWiWWhdXCzwXEVvSMpjuY8YrDAi68Z: all dials failed\n * [/ip4/216.24.57.8/tcp/443/tls/sni/relay-torrentium-3zok.onrender.com/ws] websocket: bad handshake\n * [/ip4/216.24.57.9/tcp/443/tls/sni/relay-torrentium-3zok.onrender.com/ws] websocket: bad handshake"
exit status 1
user@machine CIPHER % go run ./cmd/client -provider /dns4/cipher-sk0s.onrender.com/tcp/443/wss/p2p/12D3KooWEBxhvkASAJtmdeKWiWWhdXCzwXEVvSMpjuY8YrDAi68Z/p2p-circuit/ip4/192.168.29.200/tcp/9000/p2p/12D3KooWRuNNvk5MKMfH94VV5PwxUyYjPHTLvT1MrkmpEvD55nxK -root 4c5f04eddf968f7df7f75282541b784e48f4bae5516fc9413738bf4888e76129 -chunks 4
2026-07-15T23:42:42+05:30 INF mDNS discovery enabled
- 2026-07-15T23:42:43+05:30 FTL Failed to connect to provider error="failed to dial: failed to dial 12D3KooWRuNNvk5MKMfH94VV5PwxUyYjPHTLvT1MrkmpEvD55nxK: all dials failed\n * [/dns4/cipher-sk0s.onrender.com/tcp/443/wss/p2p/12D3KooWEBxhvkASAJtmdeKWiWWhdXCzwXEVvSMpjuY8YrDAi68Z/p2p-circuit/ip4/192.168.29.200/tcp/9000] error opening hop stream to relay: failed to dial: failed to dial 12D3KooWEBxhvkASAJtmdeKWiWWhdXCzwXEVvSMpjuY8YrDAi68Z: all dials failed\n * [/ip4/216.24.57.8/tcp/443/tls/sni/cipher-sk0s.onrender.com/ws] websocket: bad handshake\n * [/ip4/216.24.57.9/tcp/443/tls/sni/cipher-sk0s.onrender.com/ws] websocket: bad handshake"
exit status 1
```
**Environment:**
- OS: macOS (Client), Render Web Services / Docker (Server)
- Go Version: 1.21+ (or whichever version you are running)
- Version: Latest `main`
**Additional context**
*Note: This was tested by deploying the relay to multiple distinct Render services (e.g., `relay-torrentium-3zok.onrender.com` and `cipher-sk0s.onrender.com`). The consistent `websocket: bad handshake` errors across different deployments confirm that this is a persistent configuration issue, not a temporary "cold start" or spin-up delay typical of Render's free tier.*
Contributor guide
Research direction
Start at the relay server startup and its configured multiaddresses, then reproduce the failure with the documented `go run ./cmd/client` WSS provider command. Verify the relay exposes a WebSocket listener that accepts the reverse proxy's upgrade and that the client connects successfully through the Render-style WSS address.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- networking
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100