I keep getting a red error that says something like “Could not connect to server” or it just times out after a while. My username and password are correct, I triple checked them. It worked fine a few weeks ago and now suddenly nothing. Anyone know what’s going on and how I can fix it?
There’s a handful of usual suspects here, roughly in order of how often they turn out to be the actual cause:
- A firewall or antivirus is blocking it. This is the number one cause honestly. Sometimes an antivirus update quietly resets its rules and starts blocking FileZilla again even though it worked fine before. Try disabling it for a minute just to test, not to leave it off, just to see if that’s the culprit. If it connects with it off, add FileZilla as an exception in the firewall settings.
- Wrong port or protocol. Regular FTP uses port 21, SFTP uses port 22, and FTPS usually uses 990. If your host switched you over to SFTP at some point and you’re still connecting the old way, that alone will break it. Worth double checking with your hosting provider.
- Passive mode problems if you’re behind a router, since the passive ports sometimes need to be forwarded on your end. Everything looks fine but the actual data transfer just never goes through. FileZilla has a network configuration wizard under the Edit menu that walks you through this.
- The server changed or is just down. Try a different network or device to rule that out.
- Some ISPs, mobile ones especially, block port 21 outright. Switching to SFTP on port 22 fixes it more often than you’d think.
There are several matching reports in a forum case FileZilla discussion, a separate support thread FileZilla post, and an older discussion FileZilla exchange. Posting the full connection log in the community hub r/filezilla section or reading troubleshooting posts r/filezilla may also narrow it down.
If this becomes a routine problem on a Mac, the drive mounting CloudMounter option can mount the server like a normal drive and also handle services such as Google Drive or S3.
23 Likes
The hosting-panel login can be a red herring because it may use different credentials and a different server address. If FileZilla times out before showing “Connected,” the password is not the issue yet. Ask the host for the exact FTP/SFTP hostname, protocol, and port, then have them check whether your public IP was blocked after failed attempts. I’d do that before disabling the entire security suite.
The exact last line in FileZilla’s message log matters here. “Resolving address,” “Connecting to…,” and “Waiting for welcome message” point to different failures, even though they all look like a connection timeout from the main window.
If it stalls at “Resolving address,” check the hostname for an old server name or typo. If it shows an IP address and then stalls at “Connecting,” the address resolved correctly, but that port is unreachable. That usually means the wrong port, a host-side firewall block, an IP ban, or an FTP service that is not running. If it reaches “Waiting for welcome message,” the connection opened, but the server never completed its greeting, which the host needs to investigate.
I would not start by disabling the full security suite on a work computer. A cleaner test is to try the same saved FileZilla entry through a phone hotspot. If it works there, your office router, network firewall, or public IP is probably involved. If it fails on both networks in exactly the same place, send the host the FileZilla log, the time of the attempt, and your public IP. That gives them enough information to check their firewall and server logs instead of replying with “the credentials are correct.”
For a team, make sure nobody is sharing the hosting-panel account in FileZilla. Ask for separate SFTP users with access limited to the required folder. Apart from being safer, separate accounts make it much easier to identify which user was blocked or which credentials expired. Confirm the host, protocol, and port manually rather than relying on FileZilla’s Quickconnect history. An old saved entry can keep pointing at a retired server after a hosting migration.
Passive mode is worth checking only after FileZilla actually connects and logs in. It generally does not explain a timeout at the initial “Connecting” stage, so changing passive settings now could send you down the wrong path. Likewise, switching to CloudMounter would not fix an unreachable hostname or blocked port. It may provide a different interface later, but the underlying server details still have to be correct.
Before changing much else, copy the message log with the username and password removed. The final five or ten lines should make it clear whether this is DNS, basic port access, or a server response problem.
Don’t reinstall FileZilla yet. First compare FileZilla’s timeout with a basic port test from the same computer.
On Windows, open PowerShell and run:
Test-NetConnection your-server-name -Port 22
Use port 21 instead if the host says FTP or explicit FTPS. On macOS or Linux, the equivalent is:
nc -vz your-server-name 22
If that test cannot reach the port, changing FileZilla settings will accomplish nothing. The problem is outside FileZilla: wrong hostname or port, a firewall rule, an office VPN, an IP block, or a service that is down. If the port test succeeds while FileZilla still hangs, then compare the Site Manager entry against the provider’s instructions, especially SFTP versus FTP versus FTPS. Those are separate protocols, even when the username looks identical.
For a work team, run the same test on two computers. If everyone in the office fails but a remote team member succeeds, the shared office public IP may be blocked. A single person repeatedly trying an outdated password can trigger a ban that affects the whole office because the server sees everyone coming from the same public address.
I agree with @techrouter3112 that passive mode is not the place to start when the initial connection never opens. Passive-mode trouble normally appears later, around directory listings or transfers. A raw port test gives you a cleaner comparison and something specific to send the host: hostname, port, exact attempt time, and whether the TCP connection succeeded.
Two support cases stick in my head because they looked identical in FileZilla and had nothing in common underneath. One was a stall that ended in a flat timeout after about 20 seconds, and the fix was a hostname still pointing at a decommissioned box. The other timed out at the same spot but was a security suite doing TLS inspection that mangled the FTPS handshake. Same symptom, opposite cause. That’s why I like @novapanda’s port test so much. It tells you which of those two worlds you’re in before you waste an evening.
But I’d add a wrinkle to the port test that trips people up. A successful TCP connection on 21 or 22 does not mean the protocol will work. FTPS explicit still opens the plain port first, then upgrades to TLS. If your antivirus or a corporate proxy is inspecting encrypted traffic, the raw port check passes clean while FileZilla dies right after ‘Connecting’ because the encrypted layer gets broken. So if the port test says OK and FileZilla still hangs, don’t jump straight to Site Manager settings. Look at whether anything is intercepting TLS. That’s the one scenario where @turbo_hawk’s ‘disable the security software as a test’ earns its place, but only after you’ve confirmed the port is reachable, not as step one on a work machine.
The other thing worth knowing is the difference between a connection that gets refused and one that goes silent. A refusal comes back fast, usually a second or two, and points at a service that isn’t running or a wrong port. A silent drop that grinds for the full timeout usually means a firewall quietly eating the packets or a bad IP. FileZilla shows both as ‘timed out’ in the main window, so you have to read the log timing to tell them apart. @techrouter3112 is right that the last log line matters, but the time it took to fail is almost as useful.
On the team angle, everyone’s talking about shared IP bans, which is real, but the quieter problem is one person’s saved Quickconnect entry drifting out of date after a host migration while everyone else got updated instructions. Nobody thinks to compare. Have each person read out their exact hostname, port, and protocol. You’ll often find one machine still aimed at the old server.
CloudMounter came up earlier and it’s a reasonable fallback if you get tired of FileZilla’s connection quirks, but it rides on the same protocols and the same server details. If the hostname is dead or the port is blocked, mounting it as a drive fails in exactly the same way, just with a less helpful error. Fix the underlying reachability first, then decide if a different front end is worth it.
Don’t keep retrying nonstop, since some servers extend an automatic block with each attempt. What confused me was that a correct password still fails if the server only allows your old public IP. Home and office IP addresses can change without notice. Check your current public IP, send it to the host, and ask whether the FTP/SFTP account has an IP allowlist or an active ban.
If FileZilla fails with the hostname but reaches the server’s current IP, suspect stale DNS; if both fail, look elsewhere. Ask the host for the current IP, test it once, then flush your DNS cache, but don’t save the IP permanently because FTPS certificates and SFTP host keys may no longer match.