FTP/SFTP Connection Errors: Fix Login & Timeout Issues

You open FileZilla, hit connect, and get "Connection refused" or "Connection timed out." Or maybe it connects but every login attempt bounces back with "530 Login authentication failed." FTP problems are almost always one of a handful of causes, and none of them require guesswork if you check them in the right order.

First, figure out what kind of failure you're dealing with

FTP/SFTP errors fall into two buckets, and the fix is completely different depending on which one you've got:

• The connection never opens — you see "Connection refused," "Connection timed out," or the client just hangs. This is a networking or port problem.
• The connection opens but login fails — you get a "530" error or "Authentication failed." This is a credentials or account-status problem.

Match your symptom to the right section below instead of retyping your password five times and hoping.

Connection refused or times out

Check you're using the right protocol and port

This is the single most common mistake we see. FTP, FTPS, and SFTP are not interchangeable, and each uses a different port:

If your VPS only runs SSH, trying to connect on port 21 will just hang — there's nothing listening there. In FileZilla, set the protocol explicitly under File → Site Manager rather than typing ftp:// or sftp:// into the quickconnect bar and assuming it'll figure it out.

Test whether the port is even reachable

Before blaming your FTP client, confirm the port is open from your machine:

# Test FTP (port 21)
telnet yourdomain.com 21

# Test SFTP/SSH (port 22)
telnet yourdomain.com 22

# Or with netcat if telnet isn't installed
nc -zv yourdomain.com 21

If this hangs or refuses, the problem is between you and the server — not your username or password. Three usual suspects:

• Your own network or ISP is blocking outbound port 21. Corporate networks and some public Wi-Fi do this routinely. Try a different network (phone hotspot is a fast way to rule this out) before troubleshooting anything server-side.
• The server firewall is blocking the port. On a VPS with UFW, check with sudo ufw status — if port 21 or 22 isn't listed as allowed, that's your answer.
• You're connecting to the wrong host. If you recently moved to Getwebup or changed nameservers, your FTP hostname might still be resolving to the old server. Connect using the server's IP address directly to rule DNS in or out.

Passive vs active mode

FTP (not SFTP) connects fine but then hangs or drops the instant you try to list a directory or start a transfer. That's almost always an active/passive mode mismatch. Nearly every modern host, including Getwebup, expects passive mode because active mode requires the server to open a new connection back to your machine — something most home routers and firewalls block by default.

In FileZilla: Edit → Settings → Connection → FTP → Passive Mode. Make sure it's selected, not "Active."

Firewall on your end blocking the client

If you can telnet to the port successfully but your FTP client still can't connect, Windows Defender Firewall or a third-party antivirus is sometimes blocking the FTP client application itself, not the port. Temporarily disable it to test, or add an explicit allow rule for FileZilla/your client of choice.

Connection opens, but login fails (530 error)

Wrong username format

On cPanel, the FTP username for the main account is your full cPanel username. But if you created a dedicated FTP account for a specific folder, the username usually needs the full domain appended, like:

uploads@yourdomain.com

not just uploads. This trips people up constantly — the account works fine in cPanel's file manager but "doesn't exist" over FTP because the username was typed without the domain suffix.

Password was reset somewhere else

If you use a password manager, double check it actually saved the current password and isn't autofilling an old one from before a reset. Reset the FTP account password directly in cPanel under Files → FTP Accounts, copy it fresh, and paste it straight into the client rather than typing from memory.

The FTP account is suspended or the disk quota is full

cPanel FTP accounts can have a quota separate from the main account's disk allowance. If that sub-account's quota is maxed out, some servers reject the login outright rather than just blocking uploads. Check the quota value in FTP Accounts and either raise it or clear space.

Also check Security → IP Blocker and cPHulk Brute Force Protection in cPanel (or WHM if you manage the server). Too many failed login attempts — often from a saved-but-wrong password retrying automatically — will get your IP temporarily blocked, and every subsequent attempt fails even with the correct password until the block clears or you remove it manually.

SFTP-specific: key auth vs password auth mismatch

On a VPS, SFTP logins fail with "Permission denied (publickey)" when the server is configured for key-only authentication and your client is trying a password, or vice versa. Check your SSH client is pointed at the right private key file, and confirm the corresponding public key is actually present in:

~/.ssh/authorized_keys

on the server, for the user you're connecting as. A key generated after you last updated authorized_keys won't work until you add the new public key there too.

Uploads connect and log in fine, but files show as 0 bytes or transfers stall

This is usually a transfer-mode issue, not a connection issue. FTP has two transfer modes — ASCII and Binary — and getting it wrong corrupts binary files like images, zips, and databases (though most modern clients auto-detect this correctly now). If you're manually forcing ASCII mode for a database dump or image upload, switch it to Binary and re-upload.

Stalled large transfers are more often a timeout setting on either end. Increase the timeout value in your FTP client's connection settings, and if you're transferring a large file over FTP, consider using SFTP with rsync or scp instead — they resume and handle large transfers far more reliably than classic FTP.

Prevention: set this up once and stop fighting FTP

• Switch to SFTP wherever the account supports it. It's a single encrypted connection over port 22, so there's no active/passive mode nonsense and no separate data-channel port to worry about.
• Save connections in your FTP client with the exact protocol and port specified — don't rely on auto-detect, especially after a server migration.
• If you manage a VPS, keep authorized_keys backed up somewhere outside the server itself, so a lockout from a bad SSH config change doesn't leave you stuck.
• Use a distinct FTP account per project/developer instead of sharing the main cPanel login — it makes it much easier to isolate which account is causing failed-login lockouts.