my uploads are painfully slow, like way under what my internet plan should give me. one file at a time takes forever. is there some setting im missing or is this just how ftp is
few things usually fix this. first one everyone tries and it actually helps a lot. Go to Edit, Settings, Transfers, and bump up Maximum Simultaneous Transfers from the default of 2 to something like 6 to 10. FTP is weirdly bad at using your full bandwidth with just one connection, but running several at once adds up fast, there’s a whole thread on the official forum where someone walks through this exact setting.
that said, if you’re moving one huge single file instead of a bunch of smaller ones, more simultaneous transfers won’t help since it’s still just one connection carrying that file. in that case it’s usually latency or the server side that’s the bottleneck, not FileZilla itself, there’s a good breakdown of this on the forum too, upload speed being naturally lower than download and server congestion both come up a lot in that thread.
also worth ruling out wifi, if you’re on a laptop make sure it’s actually using ethernet and not silently falling back to wifi, that alone has fixed it for people in a recent thread with a similar problem.
if you’re the kind of person shuffling files back and forth constantly, some people skip a dedicated ftp client altogether and use CloudMounter, which mounts the server as a normal drive so you just drag files like local ones instead of queueing them up. doesn’t magically fix bandwidth limits but it does cut out the extra step of opening a separate app every time.
30 Likes
Don’t keep cranking simultaneous transfers higher, since some servers throttle or reject excessive connections. With thousands of small files, the real delay is usually per-file overhead, so archive them into one ZIP, upload it, then extract it server-side if your hosting panel allows that.
Check whether “Preserve timestamps of transferred files” is enabled under Transfer, since it can add server work for every upload. Watch the message log for retries, reconnects, or connection-limit errors too. If the log is clean, temporarily pause real-time antivirus scanning for that source folder, because thousands of tiny files can be scanned individually before FileZilla sends them. I’d test those before raising parallel transfers again.
There may not be a FileZilla setting that makes thousands of tiny files behave like one large upload. Each file needs its own create, permission, metadata, and close operations on the server, so the connection can sit mostly idle while those requests finish.
Check File > Site Manager > Transfer Settings for “Limit number of simultaneous connections.” That per-site limit can quietly override the higher value you set under Edit > Settings > Transfers. In the global Transfers page, verify the concurrent upload limit too, since the overall maximum and upload-specific maximum are separate caps. The queue should show how many files are actually active.
I wouldn’t spend time changing timeouts, keep-alive commands, or active versus passive mode if transfers are completing without disconnects. Those settings can fix connection problems, but they rarely make a clean small-file upload meaningfully faster. If several files are active and the log shows long pauses after each upload, the storage or hosting account is probably the bottleneck.
@nina_sudo’s archive suggestion is usually the effective workaround when server-side extraction is available. For a work site, extract into a temporary directory first rather than directly over the live files. That avoids leaving a half-updated directory if extraction fails. If archives are impractical, upload only changed files instead of sending the complete tree every time.
Uploading 10,000 files from a local SSD is a different job from uploading the same files out of OneDrive, Dropbox, or a company network share. FileZilla may be waiting for each tiny file to download, unlock, or sync before it can send it.
Copy the batch to a plain local folder first, then retry. Pause cloud sync during the test and watch disk activity. @cipher9763 is right about antivirus, but sync clients and remote source folders create the same stop-start pattern.
If the local copy runs faster, quit changing FileZilla settings. The bottleneck is before FileZilla ever reaches the server.
Don’t benchmark by uploading over the existing live directory. Upload the same batch to a new empty remote folder. Replacing files can require extra metadata checks, permission changes, and server-side cleanup that a clean upload avoids.
In FileZilla, check the default “file exists” action and make sure the queue is not stopping for overwrite decisions. Disable directory comparison during the test too. It is useful for deployments, but it adds more remote-directory work.
@hugo’s temporary-directory approach is the sensible fix here. Upload a complete versioned folder, verify it, then switch directories server-side if your hosting setup allows it. That will not improve the connection speed, but it avoids turning every deployment into thousands of individual replacement operations.
If your site entry uses SFTP, the next useful test is the protocol rather than another transfer-count setting. Open Site Manager and check the Protocol field. If your provider supports both SFTP and FTP over TLS, create a second site entry and upload the same sample batch to a new empty folder. Keep encryption enabled, leave Transfer Type set to Auto, and compare the total elapsed time instead of FileZilla’s fluctuating speed display.
A large difference points to the server’s SSH or TLS handling, not your internet connection. If both tests take about the same time, you have probably reached the per-file-operation limit that @hugo described.
The archive workaround is still sensible, but be careful with ZIP if the upload contains Unix permissions, executable scripts, or symbolic links. A tar archive usually preserves those details better, provided your server can extract it. Without server-side extraction or a deployment tool that sends only changed files, there is no FileZilla setting that removes the round trip required for every tiny file.
Quick sanity check before you touch any settings: the big number in your internet plan is almost always download, and upload is a fraction of it on most consumer lines. If you’re near your real upload cap, no FileZilla tweak or extra connection changes that. Run a plain speed test first so you know what ceiling you’re actually working with.
Make one big dummy file, say 300MB, and upload just that single file to an empty folder. That one test settles the whole argument in this thread. If the big file flies and only the thousands of tiny files crawl, you have a per-file overhead problem and no connection setting fixes it. If the big file also crawls, then it is your pipe or the server, and @root.sql is right that you are probably sitting near your real upload cap. Consumer upload is often a tenth of download, so check that before you touch anything else.
The speed number FileZilla shows is worth ignoring during this. It jumps around per transfer and tells you almost nothing on small files. Time the whole batch with a clock instead. That is the only figure that matters.
On @nina_sudo and @hugo’s archive idea, it is the right call, but it quietly depends on you having shell or a file manager that extracts server-side. Plenty of cheap shared hosting gives you a control panel that can unzip, so check that first before you spend time zipping 10,000 files only to find no way to unpack them remotely. If you do have SSH, honestly skip FTP for repeat uploads and use rsync, since it only sends what actually changed and handles the small-file round trips far better than FileZilla ever will.
CloudMounter that got mentioned up top is fine if your annoyance is the queue-and-wait workflow rather than raw speed. Mounting the server as a drive makes dragging files feel normal, but it is still moving bytes over the same connection, so do not expect it to beat your upload ceiling. Convenience, not a speed fix.
One thing nobody flagged: if this is FTPS and not plain FTP, every new connection can renegotiate TLS, and on a server without session resumption that handshake gets paid over and over on small files. That is another reason the single-large-file test is useful. It strips all of that noise out and shows you the real bottleneck in one shot.
Check whether FileZilla’s speed limit is enabled, since an old cap can stay active and make every server look slow. If it’s off, run @dima22’s large-file test before changing any more connection settings.
Before switching protocols or packing archives, check for an accidental upload limit. In FileZilla, open Edit > Settings > Transfers and clear “Enable speed limits” if checked. This removes FileZilla’s configured cap.
Then retry your upload and compare elapsed time. Leave your other settings unchanged so you isolate the result.
Its a simpler first check than rebuilding your deployment workflow. If speed stays the same, dont keep changing this setting. Continue with the large-file test already suggested.