Uploading Zip files via FTP super slow

I need to upload ZIP files on a regular basis and in the last month or so, this has suddenly slowed to a crawl. Currently getting 948kbps (which is up from the 250kbps a little while ago) a 1.1GB file has so far taken about 30 minutes.

After I Started this one, I started a second upload of about 3.6GB, of about 6000 individual image files, and this finished well before the ZIP file, averaging about 5.4Mbps up.

Has anyone else had this issue?


You should only use SFTP.

Your slow upload speed is also affected by your ISP. Do some testing to determine when the fastest upload times are.

You may have a resource hog sharing your FTP server.


Thanks for your reply. My error, it is actually SFTP that I am using. I understand what you are saying however, when uploading the individual files, it is much faster. Also, it never used to do this for ZIP files and I routinely upload 20-40+ GB of images to my BackBlaze B2 storage and to S3 and it is fast. On Saturday for instance, I uploaded 23GB to B2 and it took 43 minutes, compared to nearly 30 minutes for 1.1GB today. So, it is hard to think that it is the ISP when I getting solid speeds to DH in other ways, and to other services.

I have just tried uploading the same file to B2 and it is averaging 2.5MB/s and should take 4 minutes.

Also, I have a dedicated server, is that different to the FTP server? Or are they all located on the same machine if you have a DS?



I have never seen DH accept a pushed file over 250kbps. Not ever.

Requested files, however, come in much faster. It pays to send a request from a DH server to an external resource rather than try to push files to it.

Out of curiosity, are you using DH’s web-based file-manager (files.dreamhost.com), or a local SFTP client (command-line sftp, a GUI app, etc)?

I’ve seen up to 240 Mbps uploading (via scp) to shared hosting (when I’m on a net with that much bandwidth!).

I have a scheduled upload (not FTP) of a 305.6mb zip file from a dump I have in a cloud. I don’t watch it; it happens in the background, but nothing has alerted me to it being a problem.

But as sXi said, this is a request from my DH server to AWS.

I hit a 250kbps ceiling when pushing to DH (Shared Unlimited) over SFTP. Same connection can saturate the max upload to other hosts (AWS, Oracle, Vultr, etc.).

Ouch, 250kbps is pathologically slow. Maybe worth contacting support to get moved to a more functional shared-host? Or see if they can fix it?

FWIW, I’ve tried some tests with two shared-hosts (one in Virginia, the other in the Oregon data-center) and both accept uploads as fast as I can send (i.e. 10Mbps).

Unsure if just a coincidence or a case of the squeaky wheel getting the grease, but a test upload of a 100MB dummy file just now uploaded at between 3-11Mbps :rofl:

I’ve only kept my DH account for email purposes (haven’t hosted anything of value here since about 2014) and will be offloading the last email accounts shortly so I can cancel the now ridiculously high monthly bill.

Hi Habilis,

I was today years old when I learned that files.dreamhost.com was a thing.

So I tried that, and was getting speeds as high as 3.0MB/s which was great until it appears to have hung and I had to quit it.

I wonder why this was not suggested when I talked to support.


I have a dedicated server


Using a web interface is highly restrictive due to memory requirements.

The bottleneck is the internal network at the datacenter, not the flavor of server you have. It’s no consolation, but I think users paying for Dedicated servers should have priority where network resources are concerned.

Complain vigorously to DH Support until you get the attention of someone who actually knows what they’re doing or otherwise elevates your case to someone who can actually fix the issue.

In the interim you could upload to a capable cloud and pull the file from there to your server via script/crontab (as @keyplyr suggests above) while they sort your network out.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.