"Could not connect to the FileZilla server" error, what's causing this?

Mac
1

It just started happening out of nowhere, I didn’t change anything on my end. Any idea what usually causes this and how I can get it working again?

2

That error is pretty generic on purpose, FileZilla just uses it as a catch all whenever the client-server handshake fails for basically any reason. The usual causes, in order of how often I see them:

Wrong username or password. Sounds obvious but this is honestly the top cause, especially if your host recently reset something or your saved password in FileZilla is outdated. Retype it manually instead of using a saved one just to rule this out.

Firewall or antivirus blocking it. A firewall update can silently start blocking FileZilla again even if it worked yesterday. Try disabling it for a minute as a test.

The server is down or full. If the server hits a connection limit or is just offline, you’ll get this same message. Try again in a bit or ask your host if there’s an outage.

If this is FileZilla Server, not the client. The server software actually has two parts, the admin interface and the engine that does the real work. If the engine isn’t running as a service, the admin panel throws this exact error trying to reach it. Worth checking Windows Services to make sure it’s actually started.

Some real threads about this exact error if you want to compare logs:

For Mac users managing several FTP, SFTP, or cloud accounts, CloudMounter is an alternative that mounts services such as Google Drive and Dropbox as regular Finder drives. It won’t fix bad credentials or a dead server, but it can be less irritating than dealing with a separate FTP window every time.

My view would change if the logs showed a repeatable protocol, certificate, port, or server-configuration failure despite confirmed credentials, an active engine, and no firewall interference. Until then, I’d bet on one of the boring causes above.

21 Likes
3

Restoring the visible fields can still leave the wrong protocol selected. Check whether the Site Manager entry says FTP, FTPS, or SFTP, because SFTP on port 22 is completely separate from FTP on 21. I would read the first few log lines before disabling security software: “connection refused” points to the host, port, or server service, while an authentication failure means the client reached the server and the credentials are the problem.

4

If the same account fails from two devices, suspect the server; if another device connects, the problem is local to that FileZilla setup. Test from a different network too, since your public IP may have been blocked after repeated failed logins. That edge case looks exactly like bad settings until the server’s ban list or hosting control panel is checked.

5

If Quickconnect works but the saved Site Manager entry fails, the server is fine and that profile still contains a bad hidden setting. Delete the entry and create a fresh one from scratch instead of editing it again, paying attention to protocol, encryption mode, and logon type.

6

Using the server’s IP address as a test can expose a DNS problem, but don’t save it as the permanent fix because FTPS certificates are usually issued for the hostname.

What confused me here is that FileZilla’s message sounds like it has already contacted the server. Sometimes it has not. If the log stalls at “Resolving address,” check whether the hostname still resolves to the correct IP. A router cache, hosts-file entry, VPN, or recently changed DNS record can send this machine somewhere different even when every visible Site Manager field looks right.

Try resolving the hostname outside FileZilla, then compare that address with the expected server address. If connecting to the IP reaches a login prompt while the hostname does not, the client profile and password probably are not the main issue. Clear the local DNS cache, disconnect any VPN or proxy, and check the hosts file for an old manual entry.

If the IP test fails too, go back to the FileZilla log rather than the popup. A timeout means a different problem from “connection refused,” and both happen before credentials matter. An authentication error means the route, port, and server service are working, so that is when retyping the account details makes sense.

7

Changing passive-mode settings is unlikely to fix this unless FileZilla connects, logs in, and then hangs while retrieving the directory listing. Passive ports are used for the data connection, not the initial control connection.

Watch where the log stops. Failure before the welcome banner points to the hostname, control port, firewall, or server service. Failure after the server requests a username means the connection itself works and you should focus on authentication or account permissions.

I would avoid reinstalling or deleting server configuration files until that distinction is clear. A reinstall can preserve the bad setting or wipe useful account and certificate configuration without fixing the actual cause.

8

Before you touch anything else, check the clock on that machine. If FTPS is involved and the system time is off by more than a few minutes, certificate validation fails and you get a generic connect error that looks nothing like a time problem. It happens more often on machines that sat powered off or had a dead CMOS battery. Everyone here is right that the log tells you where it stops, and @aigurux6522 nailed the banner-versus-auth distinction, so I won’t repeat that. My only real gripe is the amount of energy going into deleting profiles and DNS caches before anyone confirms the simple stuff like time skew or a saved profile that quietly flipped to SFTP on 22. CloudMounter came up as a Mac alternative and that’s fair enough for day to day mounting, but it’s a workaround, not a diagnosis, so I’d still figure out why the connection broke rather than paper over it.

9

A connection that never gets a server greeting is very different from one that reaches the server and gets rejected for using plain FTP. In the second case, nothing on your computer needed to change. The host may have disabled unencrypted FTP, raised its minimum TLS requirements, or renewed the FTPS certificate.

That makes @opencache6029hq’s protocol check especially relevant. Look for messages such as “insecure server,” “TLS required,” “certificate expired,” or “no shared cipher.” If plain FTP was disabled, change the existing profile to the exact FTPS mode and port specified by the host rather than trying random combinations.

Be cautious if FileZilla suddenly presents an unfamiliar certificate. A routine renewal is normal, but verify the hostname and fingerprint through the hosting panel before accepting it permanently. If the required security mode is already correct, updating FileZilla may be necessary when the server has stopped supporting older TLS behavior.