Relay

Diagnostics

Connection & transfer self-check

Open this page in the browser that's having trouble. It checks whether this device can send and receive files, and explains anything that needs attention. Share the report at the bottom with support.

⚠️
You're testing from localhost. The STUN/TURN results below are not representative of what your users will see — some browsers (notably Firefox) restrict ICE gathering for loopback addresses as a privacy measure. This is intended browser behavior, not a Relay bug.

To check what your users actually experience, open this page at the same address they use — your LAN IP (e.g. http://192.168.x.x/test.html) or your domain. The Signaling server probe below is authoritative from any URL.

Running diagnostics…

Checking this browser's transfer capabilities.

Browser capabilities

Secure context (HTTPS or localhost)
WebRTC (peer connections)
Service Worker API
Service Worker registered & active
File System Access API
Streaming downloads (ReadableStream)

File-saving method

How received files are written to disk. Relay picks the best option this browser supports, in priority order — the highlighted row is the one in use.

Connectivity (STUN / TURN)

Whether this device can discover its public address and reach the relay used when a direct peer-to-peer path isn't possible.

⏳ Detecting public IP…

⏳ Checking STUN server…

⏳ Checking TURN server…

Signaling server

Verifies the WebSocket server is reachable and that relay candidates from Docker-internal addresses are rewritten in transit to other peers.

⏳ Connecting to signaling server…

⏳ Testing ICE candidate rewriting…

Share with support

Copy this report into your bug report, or into a message to the Relay maintainer.

Generating…