I’ve tried switching between passive and active mode, reconnecting to the server, and restarting FileZilla, but it still reports a timeout after 20 seconds. I’m uploading a small folder of receipt scans from my desktop, and the disconnect happens on both Wi-Fi and an Ethernet cable.
What should I check to keep FileZilla connected, and is this more likely a client timeout setting or something on the server side?
FTP can authenticate successfully and still fail because it uses a second connection for directory listings and file transfers. That was the odd part: the control connection was fine, while the data connection was getting blocked somewhere. I found the same pattern in the Server and passive reply problem discussion.
At first it looked as if the program simply froze. The listing stopped updating, then timed out. Once I understood how two-connection FileZilla worked, it became clear why. The program was trying to establish a connection that some firewall, antivirus, router, or server happened to block, politely declining to tell me which.
I checked similar reports next. The passive reply thread, Filezilla to Filezilla timeout, and Filezilla server timing out posts all pointed toward the data connection rather than a broken client.
Then I tried ftptest net, which forum regulars often suggest for isolating this problem. The Stalling on Entering Passive Mode report and its passive mode troubleshooting discussion explain why that test is useful. If the external test also fails, the issue is not limited to one local FileZilla installation.
For someone else’s server, I would briefly disable the local firewall or antivirus and retry. If I controlled the server, I would configure a passive-mode port range, open it, and forward it through the router. The New FileZilla times out! post and FileZilla timeout discussion cover that familiar NAT mess.
This is an old FTP design quirk. tools like CloudMounter connect to cloud storage over regular HTTPS don’t have this separate data connection at all, so you won’t see this specific error with them, though that’s only relevant if you’re dealing with cloud storage rather than an actual FTP/SFTP server.
Don’t raise the timeout or keep flipping modes. Since @mystic_cache711 covered blocked data connections, check whether the host limits simultaneous FTP connections. Before switching clients or trying CloudMounter, set FileZilla to a single transfer at a time and retry. Cheap/shared hosts often reject extra data sessions without a useful error, leaving FileZilla waiting until its timer expires.
The hidden downside of that timeout message is that it masks the command that actually failed. Open FileZilla’s message log and look at the last line before the disconnect: MLSD or LIST points to the data connection, while STOR usually means server permissions, storage quota, or a read-only destination. The connection-limit idea from @smartengineer2226 is plausible, but the log should narrow it down before you change more settings. For a small batch I’d use CloudMounter as the workaround, then send the relevant log lines to the host.
Changing the timeout is not the solution. If the host supports SFTP, use it in FileZilla and set CloudMounter as a fallback, since using SFTP solves the problem of an extra data channel inherent in FTP completely.
The server reply immediately after STOR matters more than the STOR command itself. A log ending around that point can describe several different failures.
If you see an immediate 550 or 553, look at the destination directory, account permissions, filename rules, or quota. If the server sends 125 or 150 and FileZilla then sits there without transferring bytes, the server accepted the upload but the FTP data channel never became usable. That supports the firewall or NAT explanation. A transfer that reaches completion but never receives 226 Transfer complete is yet another case, often involving server-side processing or a connection being dropped after the data was sent.
There is a common complication that switching active and passive modes will not necessarily expose: the router’s FTP ALG. This feature wants to rewrite FTP connection details and gets even more confusing, especially if the FTP is over TLS but then the router cannot read the encrypted commands properly. If your router has an option named FTP ALG, FTP helper, or FTP inspection, try disabling this temporarily and reconnect from scratch. A restart only of FileZilla leaves the router’s broken session tracking intact.
I wouldn’t be disabling TLS and be passing a real login credentials over plain FTP just to appease an old router feature. Use a temporary test account if the host is insistent on that diagnostic. SFTP is better if the server offers it, but an SFTP connection needs an SSH service and usually a different port. Picking SFTP in FileZilla will not magically make an FTP-only account support it.
There is a local-file edge case to check with scans stored on the desktop. If the desktop is being synchronized by OneDrive or another cloud service, make sure the files are actually downloaded and available offline. A placeholder file pending synchronization or security software scanning every document can delay FileZilla before it sends anything. In that situation the log generally has a local file access error instead of server reply, and moving one scan to an ordinary local folder is a quick way to isolate that from an FTP problem.
I agree with @megaowl5 that the log is the useful evidence, but STOR by itself does not prove a permission or quota failure. Include about ten lines before and after the timeout, with the username and host details removed. The reply codes and whether the byte counter ever moves should tell you which side stopped responding.
Up the inactivity limit isn’t a fix, but can act as a diagnostic device. If a longer one just makes FileZilla sit around waiting before declaring zero bytes moved, put it back and look at the data connection. If the upload ultimately completes after the server has spent time looking at every scan, then the server or its malware scanner is slow, and your hosting provider needs to fix that.
Rather not test your whole folder again. FTP won’t upload an entire folder as a single item, probably because it would be too simple. FileZilla makes directories and sends each scan as separate items, and one incorrect filename, a denied subfolder, or a missing local file can appear as a general connection issue.
Copy one scan to a normal local folder, rename it something plain like test.jpg, and upload it to a remote directory where you know the account can write. Then check FileZilla’s Queued Files, Failed Transfers, and Successful Transfers tabs. Those often reveal that several files uploaded while the client repeatedly retries one troublesome item.
If that test works, add the scans back a few at a time. Look for long filenames, unusual punctuation, duplicate names that differ only by capitalization, or a subdirectory FileZilla cannot create. Some servers reject those cleanly with a 550; others behave less helpfully and leave the client waiting.
If the plain test file hangs at zero bytes after a 150 reply, then @alpharouter9644’s data-channel explanation is the stronger diagnosis. If the byte counter starts moving, the basic FTP connection works and the failure is more likely tied to a particular file, path, or server-side processing. That distinction saves a lot of random mode switching.
The 20 seconds is not a conversation between the server and you. This is FileZilla’s default idle timeout, which has nothing to do with server-side timeouts or the location of the block. Every time the transfer is stalled (no bytes are being sent), this timer is triggered, and it seems suspiciously regular.
I mostly agree with @cyberrouter about testing a single plain file first, that’s the fastest way to stop guessing. The FTP ALG point from @alpharouter9644 is the one I’d chase hardest though, because a stale ALG session survives a client restart and quietly mangles the passive reply, so you end up blaming the wrong thing for an hour.
On CloudMounter, I wouldn’t rely upon this as a fallback as this is presented here, because it doesn’t inform you of what is failing on that FTP-only account. In areas where it is helpful, it mounts the remote as a regular drive, so you can just drag the receipts in via the file manager, thus avoiding the queue/retry loop of FileZilla completely. Useful for getting the folder up while the host deals with their end of the problem, but not a diagnostic tool.
Try testing with one simple file across a phone hotspot. If it works, then your stall is somewhere in your regular connection path, almost certainly your router or ISP throttling FTP, and changing settings inside FileZilla or global timeouts will only paper over the problem.