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

[adarshxsh]

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:

   go run ./cmd/client -provider /dns4/your-render-app.onrender.com/tcp/443/wss/p2p/<RELAY_PEER_ID>/...

3. See error output:

   - 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

  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.

[adarshxsh]

While testing our relay deployments, I ran into this exact websocket: bad handshake error when deploying to Render.

After investigating, I tracked down the root cause: Render's reverse proxy terminates the TLS wss:// connection and forwards it as ws://. Because our current libp2p host isn't configured with a WebSocket listener to handle that HTTP upgrade, the connection is instantly rejected.

While a quick fix would be to just add a /ws listener to libp2p.ListenAddrStrings, I've decided we should move away from using reverse-proxied platforms like Render for the Relay node entirely.

Running a libp2p relay behind a standard HTTP reverse proxy introduces significant architectural problems for our P2P network:

1. Protocol Restriction: Reverse proxies force all traffic over WebSockets (TCP). We lose the ability to leverage UDP/QUIC, which is crucial for modern, high-performance P2P transport.
2. NAT Traversal Breakage: Direct Connection Upgrade through Relay (DCUtR) relies on the relay accurately observing and reporting the raw public IP addresses and ports of the peers. Proxies mask this data, severely degrading our ability to successfully hole-punch.

The Architectural Solution

Instead of patching the WebSocket listener, I have built a completely new, robust transport codebase located in Adarsh/p2p_transport.

As part of this architectural overhaul, the Relay is now explicitly designed to be deployed on a dedicated Virtual Machine (VM) with a direct public IP address, bypassing reverse proxies entirely.

By deploying on a VM (such as an Ubuntu server, DigitalOcean Droplet, or AWS EC2), the Relay listens natively on raw TCP and UDP ports. As outlined in the new Relay Deployment Guide, the setup now looks like this:

1. Native Port Binding: The relay natively binds to TCP and UDP 4001, completely avoiding HTTP/WebSocket overhead.

   "Ensure your server's firewall has the following ports open for inbound traffic: TCP 4001, UDP 4001 (for QUIC)"

2. Direct Public Exposure: The relay advertises its direct public IP, allowing peers to connect natively and the relay to accurately read their IPs for DCUtR.

   "If your server's public IP is 203.0.113.50, your public relay multiaddress is: /ip4/203.0.113.50/tcp/4001/p2p/..."

Because the PR I've created introduces this entire new transport module and establishes the VM architecture—inherently eliminating the proxy constraints causing this issue—I am going to merge that PR as the definitive, long-term fix for this problem.