How to stay on a direct connection
These improve your odds of a direct connection:- Use a normal home or personal Wi-Fi network.
- When the two devices are in the same place, put both on the same Wi-Fi network.
- Disconnect from any VPN.
- Avoid strict corporate and university networks.
- Try a personal mobile hotspot when you cannot avoid one.
What counts as one session
A session is one sender and one receiver. The room holds exactly two people, so only one recipient is ever connected at a time. Each connection is checked on its own, and earlier transfers do not count toward the 2 GB. With a request link, each drop is its own session. The sending app checks once, before any file data moves. When the connection turns out to be relayed, it compares the total size of everything you queued against 2 GB and either allows the whole transfer or refuses it. It is not a meter that stops you partway, so a 3 GB batch over a relay is declined up front rather than truncated at 2 GB. A request link adds a second check on the receiving side, which can stop a drop partway: see How the cap is enforced. Exactly 2 GB is allowed. Only more than that is refused. Starting a new transfer runs the check again from scratch, so splitting a large batch into pieces under the cap works. Each drop through a request link is checked on its own the same way. Deliberately cycling sessions to get around the cap goes against the spirit of a free service.What you see when it stops you
In the browser, nothing is sent, and the sending page shows three things:- The status line
Transfer blocked. Relay limit exceeded. - An amber notice: “Transfer limit exceeded. Relay connections are capped at 2 GB. Reload the page to send 2 GB or less, or to send from a network that supports a direct connection.”
- The cap after the total in the file count line, for example “3 · 2.5 GB / 2 GB”.
Output
Turn off Hide my IP to send larger files when Hide my IP is on.
On a request link’s page, a sender whose connection turns out to be relayed sees a card titled
“Relay limit” and nothing is sent. With Hide my IP checked and more than 2 GB picked, the page
never connects: Send stays off, and the page reads “Relayed drops are capped at 2 GB. Turn off Hide
my IP, or send 2 GB or less.” When the link maker’s Floe Desktop stops the drop partway instead, the page reads “Relayed drops
are capped at 2 GB”, and the files saved before that stay on their computer. See
Sending through a request link.
In every case the sending app tells the receiving side why the transfer stopped.
One case that catches people out
Floe Desktop’s Hide my IP address setting, and the CLI’s--relay-only flag, route every transfer through the relay on purpose, so the other person never
sees your IP address. While either is on, the 2 GB cap applies to every
transfer, even on a network that could easily have connected directly. Turn it off, or drop the
flag, to send more. On a request link’s page, the Hide my IP (relay only, 2 GB per drop)
checkbox does the same to that drop. The glossary lists every name
Hide my IP goes by.
You never need to turn relay fallback off to send something large. The cap applies only when the
connection actually ends up relayed, so leaving fallback on costs a direct transfer nothing and
saves the transfer that would otherwise have failed.
Two other limits, which are not Floe’s
A browser receiver keeps what it receives inside the browser until you leave the page, so how much it can take depends on the browser and on the size of the whole transfer. A phone holds less than a computer, and how much depends on the phone. See Known limitations for what each browser can hold, and what to do when the receiver is a phone. Floe Desktop and the CLI write straight to disk as bytes arrive and have no such ceiling, which makes them the better choice for anything multi-gigabyte. Your disk is the other one. Nothing checks that the receiving device has room before the transfer starts, except for a request link. There, Floe Desktop checks before each file that the drive will keep 2 GB free after it, and stops the drop if it will not. Every other limit and timeout, with its number, is in Limits.How the cap is enforced
The cap is 2 × 1024 × 1024 × 1024 bytes (2,147,483,648), which Floe’s messages write as 2 GB. It is local policy on the sending side, applied identically by the web app, the desktop app, and the CLI. It is not part of the wire protocol, and an ordinary receiver runs no relay check of its own. A request link is the exception. The Floe Desktop that receives the drop also reads the route itself when the drop is accepted. If the route is relayed, it refuses any file that would take the drop past 2 GB. The files saved before that one stay saved, so this check can stop a drop partway. It catches a relayed drop that got past the sender’s own check. The sender inspects the network path that actually won once the connection is established. A direct connection always passes. If the route cannot be determined, the sender allows the transfer rather than blocking a legitimate one. That is deliberate: a probe hiccup should never stop a transfer that would have worked. The consequence is that a relayed transfer over 2 GB goes ahead in the rare case where Floe could not tell it was relayed. For self-hosters: the limit lives inRELAY_SIZE_LIMIT in client/lib/relay.ts and
RelaySizeLimit in cli/engine/transfer/relay.go, which the desktop app also reads for that
receiving-side check. It is compiled into all three clients rather than served by the
signaling server, so raising it on a
self-hosted instance means building the clients from modified source. See
TURN relay, which sets up the TURN relay itself.