Firewalls and VPNs
The most common reason flat.social won't connect on a work network, and exactly how to fix it.
Last updated:
Why do firewalls and VPNs block flat.social?
Flat.social carries live audio and presence over WebRTC, the real-time technology behind low-latency voice and video. WebRTC prefers a direct UDP connection, and many corporate firewalls and VPNs block or throttle UDP. That is the single most common reason flat.social connects fine on home Wi-Fi but fails on a managed office network or while connected to a company VPN.
The good news: flat.social is built to fall back to a secure connection over port 443, the same port your browser uses for normal HTTPS. So even strict networks can work once a few hosts are allowlisted.
Flat.social runs its own media server (built on LiveKit) at livekit.flat.social. You only need to allow flat.social's own hosts below, not a third-party video vendor.
Quick fixes to try yourself
If you are not on a managed network, you can usually fix this in under a minute. Turn off your VPN and reload the page. If that works, your VPN was the cause, so either keep it off for flat.social or switch it to split-tunnel mode and exclude flat.social.
If you are on an office network, switch to a personal hotspot to confirm the problem is the network, then send the allowlist below to your IT team.
Quick checklist
- 1Turn off your VPN
Disconnect the VPN and reload flat.social. Many VPNs block UDP or route real-time traffic through distant servers.
- 2Try a personal hotspot
Tether to your phone for a minute. If flat.social works there, the office network is blocking it, not your device.
- 3Use split tunneling
If you need the VPN on, set it to split-tunnel and exclude
flat.socialso flat.social traffic goes direct. - 4Send IT the allowlist
If it is a work firewall, share the hosts and ports below with your IT team. See Connection issues for other causes.
For IT teams: allowlist flat.social
To let flat.social work on a managed network, allow outbound traffic to the hosts below. The bare minimum for connectivity is TCP 443 to all flat.social hosts, which lets flat.social connect through a secure TURN relay even when UDP is blocked. For the best call quality and lowest latency, also allow the UDP ranges so clients can connect directly.
| Purpose | Host | Port | Protocol |
|---|---|---|---|
| Web app + sign-in | flat.social, app.flat.social | 443 | TCP (HTTPS) |
| Real-time signaling | livekit.flat.social | 443 | TCP (WSS) |
| Secure relay (TURN/TLS) | livekit-turn.flat.social | 443 | TCP (TLS) |
| Direct media (best quality) | livekit.flat.social | 50000–60000 | UDP |
| Relay media fallback (TURN) | livekit-turn.flat.social | 3478 | UDP |
| ICE/TCP media fallback | livekit.flat.social | 7881 | TCP |
Minimum to connect: outbound TCP 443 to flat.social, livekit.flat.social, and livekit-turn.flat.social.
Best experience: also allow outbound UDP 50000–60000 and UDP 3478 to the LiveKit hosts above.
Deep packet inspection, SSL/TLS interception, and proxies that rewrite WebSocket traffic will break flat.social's signaling and TURN connections. Add livekit.flat.social and livekit-turn.flat.social to your inspection bypass list.
If your VPN must stay on, split tunneling that excludes *.flat.social gives the best results. Forcing all real-time media through a single VPN exit node adds latency and often blocks UDP entirely.
Still blocked after allowlisting?
If flat.social still will not connect, confirm UDP is reaching the media ports, since some firewalls silently drop UDP even when a rule exists. As a test, allow only TCP 443 to the three hosts: flat.social should still connect through the secure relay, just with slightly higher latency. If that works, the remaining issue is UDP filtering. If even TCP 443 fails, a proxy is likely inspecting or rewriting the connection.