Direct connections and relay
One service URL discovers the available network paths.
Connection sequence
- Complete device discovery, pairing and the encrypted handshake through the service.
- Gather LAN, IPv6, public STUN and optional self-hosted probe candidates.
- Native clients try WebRTC/UDP and native TCP paths in parallel; browsers try WebRTC.
- If direct connection fails, use the service's encrypted WebSocket relay when permitted.
Public and self-hosted probes assist direct connections in parallel. Once connected directly, application data flows between devices; signaling still maintains device state.
Native and browser capabilities
| Capability | Native desktop/mobile | Browser |
|---|---|---|
| WebRTC data channel | Supported | Depends on browser environment |
| Native TCP hole punching | Supported | No raw TCP socket API |
| Encrypted WebSocket relay | When service permits | When service permits |
| Host local agents | Desktop only | Not supported |
HTTPS and ports
Configure the service root URL, such as https://reignhub.example.com. Probes are discovered through /p2p/config. Cloudflare Workers provide HTTPS/WSS.
Browser cryptography, clipboard and some connection capabilities require a secure context. Use HTTPS on the public Web; localhost has a development exception. An HTTP page loading does not guarantee full remote-control functionality.
When hole punching fails
NAT, firewalls and enterprise Wi-Fi isolation can prevent direct access. Official Free has no official traffic relay entitlement. Paid plans may provide relay when available; an open-source self-hosted Worker provides your own relay.
The optional probe adds TCP/UDP candidate discovery; the Worker handles application relay. See Deploy a probe.