What is Peer Relay?
A peer relay is the server that bandwidth-sharing devices connect out to, and through which customer traffic is handed down to those devices. Because each device dials the relay and keeps the connection open, it needs no public address and no open port, which is how phones and home lines behind NAT or CGNAT can act as proxy exits.
The design is a backconnect arrangement turned inside out. The customer connects to a gateway; the device has already connected to a relay; the relay pairs the two and passes bytes between them. The device never has to accept a connection from outside, which removes the port-forwarding problem that would otherwise rule out every phone on a carrier network and most home routers.
On PROXIES.SX the sequence is published in full. A device registers and receives a JWT valid for one hour, a refresh token valid for seven days, and the URL of its assigned relay. It opens a WebSocket to that relay with the JWT in the Sec-WebSocket-Protocol header. Relays are regional, and the platform assigns the nearest one, for example relay-us.proxies.sx for US and Latin American peers, because "a far relay caps a single TCP stream by latency"; a relay_redirect message moves a peer when a nearer one exists. The peer sends a heartbeat every 30 seconds, and a peer silent for 120 seconds is closed and marked offline.
Customer traffic arrives as tunnels. The relay sends a JSON tunnel_connect message with a session ID, host and port; the device opens a TCP socket to that host and answers tunnel_connected; bytes then flow both ways untouched, as binary WebSocket frames when the device has advertised the binary-v1 protocol. A device may hold up to six WebSockets, and the Node.js reference client, version 1.6.0, opens four by default. The older proxy_request message is deprecated for new clients.
The failure the contract warns about most is a client that accepts the tunnel and completes a fast handshake but never forwards the TLS bytes, so it looks healthy while carrying nothing. The relay expects the first data within five seconds of tunnel_connect, and three such failures unlist the device. A self-test, POST /v1/peer/my-devices/{id}/test, runs the same CONNECT, TLS and HTTP request a customer would make once the device is online. Any client method is accepted as long as the IP is real, the traffic flows through the device and it speaks the relay protocol.
Where you meet it
You meet the peer relay when you write or debug a bandwidth-sharing client, or when you wonder why a device on your network holds one long-lived outbound connection to a single host. It is also the answer to the common question of how a phone with no public IP can serve as a proxy at all.
Common questions
Why does a bandwidth-sharing device connect to a relay instead of opening a port?
Most phones and many home connections sit behind NAT or carrier-grade NAT and cannot accept inbound connections. An outbound connection to a relay works through both and needs no router changes, because customer traffic reaches the device over a connection the device itself opened.
What is tunnel_connect?
It is the PROXIES.SX relay message that starts a customer tunnel. It carries a session ID, a host and a port; the device opens a TCP connection to that host and port, replies tunnel_connected, and then relays bytes in both directions without modifying them until either side closes.
Why is my device online but carrying no traffic?
Being online is not the same as being listed. A PROXIES.SX device needs at least an hour online, a quality score of 50 or more and the minimum speed before it is routed customers, and a client that drops TLS bytes after the handshake gets unlisted. Run the self-test to check the tunnel path, and GET /v1/peer/my-devices/{id}/verification for the listing checks.
Related terms
Real 4G/5G mobile and residential IPs
PROXIES.SX runs carrier IPs in 100+ countries with HTTP and SOCKS5 on every endpoint. $4/GB down to $2.40/GB at volume, free endpoints and rotation, and your GB never expire.