Direct, server route and routed networks: which way works?
What “direct” really means, when pipeit routes through its servers and what you can check.
Direct means the file data flows between the devices without being forwarded by a pipeit data relay. That can work on the same LAN, between routed networks or over a reachable internet connection. Through pipeit means a relay forwards the end-to-end encrypted data. The connection details tell you which route was used.
An online direct transfer can still need servers for sign-in, permissions and setting up the connection. So “direct” is not the same as “without any server contact”. Conversely, a server route is not a backup and no promise of a file you can fetch later.
Which route fits which situation
| Devices and situation | Direct file transport | Alternative and conditions |
|---|---|---|
| Browser to browser, small supported file route | A WebRTC data channel, when the actual probe and negotiation succeed | Server route when the service is reachable and the policy allows it; both browsers open |
| Browser to browser, large files | Encrypted pipeit relay, up to 8 GiB per file | Both browsers stay open until the transfer finishes |
| Browser to native client | Direct when both sides offer a common direct route | Otherwise through pipeit; native TCP is not browser TCP access |
| Native client to native client on a LAN | TLS over TCP with a released listener and a fitting receive policy | Server route, if allowed |
| Native devices in different routed networks | TLS over TCP when the advertised concrete address and port are reachable | The same subnet is not required; routes, firewall and listener decide |
| Native devices behind NAT | Direct only with an endpoint or mapping that is actually reachable | No universal NAT traversal; server route or deliberate network configuration |
| Browser on a restrictive network | WebRTC can fail | TURN, where available, already is a relay; an additional WebSocket route is a transport of its own |
| The direct route drops after acceptance | New attempts according to the contract and state | Allowed fallback with a note and the route in the history; no silent redirect when the fallback is forbidden |
| Slow connection | Possible when the route is stable and the time budget sufficient | Compare another route deliberately; a server route is not automatically faster |
| No internet, but a reachable local or routed network | Separately paired native offline peers over TLS | Not a replacement for the online account or server route; needs its own local trust setup |
| No usable network path | No transfer | Neither a QR code nor the server route replaces a missing connection |
| Nearby, between the pipeit apps (Wi-Fi Aware, Wi-Fi/LAN, Bluetooth discovery) | Direct, without router or internet; works across iPhone, Android, Windows, Mac and Linux | The route used is shown in the connection details; server route only when the devices are not nearby |
Scroll sideways to see the whole table.
Understanding the pre-check
After you pick a device, a supported client checks one concrete direct route. It shows success, unknown or error with a short reason. A probe can expire; a phone unlocked later or a network change can alter the result. Check again starts a new probe, not a file transfer.
Direct possible is no speed promise. Direct not confirmed yet is no blanket statement about all conceivable protocols or ports. Chosen through pipeit means a direct check can be skipped for this deliberate choice; that is not a direct failure.
Choosing direct or the server route
Automatic tries a suitable route according to your settings. Through pipeit chooses forwarding explicitly. If you only want direct, the fallback that applies to the job must be forbidden as well. In the web app, the matching choice does that. In the CLI, --route direct alone is no general proof of a forbidden fallback: check the account policy snapshot and the result, see Check the direct route and set the fallback.
Only after a confirmed completion do you know which route actually delivered the file. A “direct” display during an attempt must not later serve as proof for the whole job if the transfer then switched to the server route.
Why not try all ports?
A client publishes its own suitable endpoints and checks authorized counterparts. pipeit is no arbitrary port scanner and does not promise to cross every firewall. A free port has to belong to a listening, authenticated pipeit receiver. A ping proves only part of the reachability and no write right. Routed networks need no special file form: what matters is a reachable and authorized receiving route.
Comparing speed properly
Small files often measure sign-in, preparation and connection setup more than throughput. Large directories can be limited by many file accesses and hashes. Other factors are Wi-Fi, packet loss, VPN, CPU, browser, the receiver’s disk, encryption and the server route. Compare values with source, target, file size, route and version.
Related guides
- Apps and browser
Check the connection and look back at it later
See which route is checked before sending and which one was actually used afterwards.
- Command line and servers
Check the direct route and set the fallback
Probe a direct route, choose a route per transfer and control the account-wide fallback.
Connectivity: nearby, WebRTC, TLS, routing and ICMP
How devices find each other nearby and across networks, why a routed network needs no special format and what the ICMP path for locked-down Linux hosts does.
Still stuck?
Check the troubleshooting guide first. If that does not help, tell us what happened.