devlup-labs / devlup-labs/CIPHER

[BUG] : Relay server fails WSS connections behind reverse proxy

Open
#8 1 comment 0 reactions 0 assignees View on GitHub
bug
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.