Diagnosing 'Critical error: Could not connect to server' in FileZilla Client

Recognizable Condition

When attempting to connect to an FTP/FTPS server, FileZilla displays the message Critical error: Could not connect to server and the connection attempt stops. The status pane may show a timeout after a few seconds, or it may immediately abort with no further detail.

Cause/Diagnostic Table

Possible Cause	Typical Symptom in Log	Diagnostic Clue
Client‑side firewall blocking data connection (Active mode)	Log shows Entering Active Mode followed by timeout	Server IP appears in log but no data‑channel packets reach client
Server passive port range blocked by network firewall	Log shows Entering Passive Mode then timeout	Client initiates PASV, server replies with IP and high port, but connection to that port fails
TLS/SSL mismatch (explicit FTPS required, client set to plain FTP)	Log shows TLS handshake failed or Server sent unexpected message before timeout	Authentication succeeds but encryption negotiation aborts
Wrong protocol port (e.g., using port 21 for SFTP)	Immediate rejection: Connection refused or Invalid response	Port number does not match service listening on that port

Ordered Checks

1. Inspect the message log – Open View → Message log. Look for the first line after Status: Connecting to …:
   • Entering Active Mode → suspect client‑side firewall/NAT.
   • Entering Passive Mode → suspect server passive port range or intermediate firewall.
   • Any TLS handshake error → suspect encryption mismatch.
   • No mode line and immediate abort → check port/protocol.
2. Verify Transfer Settings mode – Edit → Settings → Transfer → FTP. Note whether Passive mode, Active mode, or Default is selected. Change to the opposite mode temporarily to test.
3. Test raw port connectivity – From the client machine run a command‑line test (requires no admin rights):

   # Replace SERVER and PORT with actual values
   nc -vz SERVER PORT
   # or, if nc unavailable:
   telnet SERVER PORT
   

   Test:
   • Port 21 (control) – should succeed.
   • If using passive mode, test a high port from the server’s PASV reply (e.g., 50000‑50100).
   • If using active mode, test a client‑side high port that the server would try to connect to (you can listen locally with nc -l PORT and see if the server reaches it).
   Success shows Connection to SERVER PORT port [tcp/*] succeeded!; failure shows timeout or connection refused.
4. Check TLS/SSL settings – Edit → Settings → Connection → FTP → TLS. Ensure:
   • If the server requires explicit FTPS, Require explicit FTP over TLS is enabled.
   • If the server uses implicit FTPS, select Implicit FTP over TLS and set port to 990.
   • If the server is plain FTP, disable TLS.
5. Review firewall/NAT rules – On the client side, ensure outbound connections to the server’s passive port range are allowed. On the server side, confirm the passive port range is opened in any perimeter firewall and that the PASV address advertised matches the server’s public IP.

Fixes Tied to Findings

• Active mode blocked by client firewall/NAT:
  • Switch to Passive mode in Transfer Settings.
  • If Active mode is required, add an outbound rule allowing the server to connect to a client‑side high port range (e.g., 50000‑51000) and configure the client’s Active mode ports accordingly.
• Passive mode ports blocked:
  • Ask the server administrator for the configured passive port range (often PassivePorts 50000 51000 in vsftpd).
  • Open those ports in any firewall between client and server.
  • If you control the server, adjust the passive port range to a set that is already open.
• TLS/SSL mismatch:
  • Match the client’s encryption setting to the server’s requirement (explicit vs implicit FTPS, or plain FTP).
  • If the server uses a self‑signed certificate, enable Allow insecure server certificate temporarily for testing.
• Wrong protocol/port:
  • For SFTP, ensure Protocol: SFTP – SSH File Transfer Protocol is selected and port set to 22.
  • For FTP/FTPS, keep protocol as FTP - File Transfer Protocol and port 21 (or 990 for implicit FTPS).

Escalation Criteria

If after performing the checks above the connection still fails:

1. Collect the full message log (including timestamps) and the server’s FTP log (if accessible).
2. Verify that the server is reachable via ping or traceroute to rule out network routing issues.
3. Contact the server administrator with the log excerpts and ask:
• What passive port range is configured?
• Is explicit FTPS enforced?
• Are there any intrusion‑prevention rules that could reset the connection?
4. Consider testing with an alternative client (e.g., lftp or WinSCP) to isolate whether the issue is FileZilla‑specific.