File transfer blocked or slow on this network? How to diagnose and fix it

If a browser-to-browser transfer connects fine at home but fails or crawls on an office, school, hotel or café network, or whenever your VPN is on, the cause is almost always the network rather than the file or the browser. Peer-to-peer tools built on WebRTC need either a direct UDP path between the two devices or a relay server, and restrictive networks remove one or both. The fastest test is to put one device on a different network, such as a phone hotspot or home broadband, and try again. If that works, read on to pin down why the original network failed, and remember that on a managed network the rules are your organisation's to set, not yours to bypass.

Match your symptom to a likely cause

What is actually getting in the way

UDP blocking

WebRTC prefers UDP because it handles reliability itself. Many corporate and school firewalls allow little more than web browsing on TCP ports 80 and 443 and drop other outbound UDP. With no UDP, the browsers cannot punch a direct path. The only way through is a TURN relay reachable over TCP or TLS, which many relay services offer and the TURN standard (RFC 8656) supports. If the relay is blocked too, the connection fails.

Strict ("symmetric") NAT

Direct connections depend on the router keeping the same public port for a device no matter who it talks to. The IETF's NAT behaviour requirements (RFC 4787) make that behaviour mandatory and note that failing to provide it "will force the use of a UDP relay". Some enterprise firewalls and carrier-grade NAT on mobile networks still allocate a fresh port for every destination. MDN describes this restriction as symmetric NAT and explains that TURN exists to get around it. One device behind strict NAT can often still connect directly to a well-behaved home router; two strict NATs almost always need a relay.

Captive portals

Hotel, airport and café Wi-Fi often holds you in a "walled garden" until you accept terms or enter a room number. The IETF's captive portal architecture (RFC 8952) describes an enforcement device that discards traffic from devices that have not yet met the portal's conditions. Your phone may show full Wi-Fi bars while everything except the sign-in page is blocked. Portals can also re-trigger after a timeout, dropping a long transfer midway.

Client isolation

Guest and public networks commonly stop connected devices from reaching each other, so a stranger in the lobby cannot probe your laptop. It also means two of your devices on that Wi-Fi cannot connect locally. Traffic must go out to the internet and come back, which some routers do not allow, leaving a relay as the only route.

Deep packet inspection and throttling

Some networks inspect traffic to classify it, then block or slow categories such as peer-to-peer, video or unknown encrypted UDP. The content is still encrypted, but the pattern of packets can be recognised. Symptoms range from a connection that never forms to one that starts fast and is then squeezed down to a trickle.

VPNs

A VPN changes the route your traffic takes. Some VPN apps do not carry UDP well, some block WebRTC to prevent IP address leaks, and browser privacy settings or extensions can restrict which network interfaces WebRTC may use. When both peers are on VPNs, the path may also be long and congested. None of this is a fault in the VPN; it is doing its job of controlling traffic.

Step-by-step diagnosis

1. Confirm basic internet access. Open a news site in a new tab. If you are redirected to a login or terms page, complete it, then reload the transfer page on both devices.
2. Keep both devices awake and the tab in front. On phones, a locked screen or switching apps can suspend the page and drop the connection. Rule this out before blaming the network.
3. Try a different browser. A current version of Chrome, Edge, Firefox or Safari should all work. A browser with strict privacy extensions, or a locked-down corporate build, may restrict WebRTC.
4. Pause the VPN, if you are allowed to. If the transfer then works, look in the VPN app for options related to UDP, split tunnelling or WebRTC protection, or simply accept that transfers need the VPN off.
5. Change one side's network. Put the phone on mobile data or tether the laptop to a hotspot, again only where permitted. If the transfer now succeeds, the original network is the cause.
6. Look at the connection details using the browser's WebRTC diagnostics, described next.

Reading chrome://webrtc-internals

Chrome and Edge include a diagnostics page that records every active WebRTC connection. Open chrome://webrtc-internals (or edge://webrtc-internals) in a new tab before you start the transfer, then start it in another tab. Firefox has a similar page at about:webrtc. Safari has no comparable built-in page.

What to look for:

• ICE connection state. A sequence that ends in "connected" or "completed" means a path was found. Ending in "failed" means every candidate pair failed its checks.
• Gathered candidates. If you see only "host" candidates and no "srflx" (server-reflexive) ones, the device could not reach the STUN server, which suggests UDP is blocked. No "relay" candidates means the TURN server was unreachable as well.
• The selected candidate pair. If the local or remote candidate type is "relay", traffic is going through a TURN server. That usually explains a slow transfer on a fast connection.
• bytesSent and bytesReceived. If these climb steadily, data is flowing and the bottleneck is speed rather than connectivity.

Our WebRTC explainer covers what host, server-reflexive and relayed candidates are and why ICE tries them in that order.

Fixes, from least to most effort

When the network is fine but the transfer is slow

Not every slow transfer is a blocked one. A live transfer runs at roughly the slower of the sender's upload and the receiver's download speed. Home broadband often uploads at a fraction of its download speed, so a "500 Mbps" connection may only send at 20 to 50 Mbps. Busy public Wi-Fi shares its capacity among everyone in the room. If webrtc-internals shows a direct (non-relay) path and steady byte counts, the network is working and simply has limited capacity. Our transfer time calculator shows what speed to expect for a given file size.

A few habits help on any network: move closer to the Wi-Fi access point or use a cable, pause cloud backups and large downloads on both devices, and avoid running several transfers in parallel on one connection.

When a live transfer is the wrong tool

TransferFiles.net connects browsers directly over WebRTC and falls back to a TURN relay when a direct path is impossible. That covers most home, mobile and many office networks, but no peer-to-peer tool can get through a network designed to stop exactly that kind of traffic. On a network that blocks P2P and relays, a hosted upload service that works over ordinary HTTPS is the better choice, as is any company-approved file sharing system. Our user guide lists the basic requirements for a live transfer, and the guide to sending files without Wi-Fi limits covers transfers over mobile data.

Sources

• MDN: Introduction to WebRTC protocols (ICE, STUN, NAT, TURN)
• RFC 8445: Interactive Connectivity Establishment
• RFC 8656: Traversal Using Relays around NAT (TURN)
• RFC 4787: NAT Behavioral Requirements for Unicast UDP
• RFC 8952: Captive Portal Architecture
• WebRTC Glossary: webrtc-internals
• Chrome for Developers: chrome.privacy API (WebRTC IP handling policy)