so I’ve been using this same sftp login for months no problem and today it just stopped working. filezilla just sits there after “connected, waiting for welcome message” or whatever and then eventually gives up with a timeout. I can still ssh into the box fine with putty so I know the server itself is up. tried restarting filezilla, tried restarting my pc, nothing. anyone seen this before
seen this a bunch. since putty works fine, it’s almost never the server, it’s filezilla specific. main culprit is usually your firewall or antivirus blocking fzsftp.exe, the little helper process filezilla uses just for SFTP. it’s separate from filezilla.exe so it can get blocked even if the main app is allowed through.
less common but it happens, something on the SSH login side like a script that prints output on login can make filezilla hang like this too, there’s a thread about someone tracking that down.
if you’re on mac and get tired of client specific connection issues like this, CloudMounter is worth knowing about, it mounts the server as a normal drive in Finder instead of using a separate connect button. not a fix for your firewall thing, just a decent alternative setup.
21 Likes
Don’t start opening random FTP ports. SFTP uses the SSH port only, usually 22, so passive-mode settings and port ranges are irrelevant. Check FileZilla’s log to see which IP it resolves, especially if the hostname has both IPv4 and IPv6 records. PuTTY may be reaching IPv4 while FileZilla tries a broken IPv6 route, which looks exactly like a timeout before authentication even starts.
If the server’s SSH log shows no connection attempt when FileZilla times out, stop looking at credentials. Run Test-NetConnection hostname -Port 22 on Windows or nc -vz hostname 22 elsewhere. A failed test confirms DNS, routing, VPN, firewall, or IPv6 trouble. If the server does see the attempt, check IP bans or allowlists because tools such as fail2ban may silently drop connections instead of returning an authentication error.
Testing from the same LAN can mislead you because some routers don’t support NAT loopback, so the public hostname times out internally. Try the server’s private IP locally or test the public hostname from a phone hotspot; if only the local test fails, check split DNS or hairpin NAT.
Open the PuTTY event log and FileZilla status log side by side, then compare the actual destination rather than the saved session names. Check the resolved IP, port, IPv4 versus IPv6, and whether PuTTY is using a proxy, VPN route, bastion host, or saved tunnel. A working PuTTY session can hide quite a lot of configuration. If it reaches the server through a jump host while FileZilla connects directly, the results are not really comparable.
The last message in FileZilla’s log tells you which category to investigate. If it never gets beyond “Connecting to…,” credentials have not entered the picture yet. If you see the SSH banner or host-key exchange, TCP connectivity is working. If authentication succeeds but it stalls while initializing SFTP, then check whether the account is allowed to start the SFTP subsystem, whether its chroot paths and permissions are valid, and whether the server is configured for internal-sftp or an external subsystem binary.
For a clean comparison, try the server’s numeric IP in FileZilla and explicitly enter the same port shown in PuTTY. Create a new FileZilla site entry rather than reusing an old one, since stale proxy settings or an accidentally selected FTP protocol can waste time. The network configuration wizard and passive FTP ranges do not apply to SFTP.
If the two clients still behave differently, capture a short connection attempt with Wireshark. Repeated SYN packets with no reply point toward filtering or routing. A TCP reset means something actively rejected the connection. A completed handshake followed by silence moves the problem higher up the SSH stack. That distinction is much more useful than the word “timeout,” which FileZilla can display for several different stages.
A timeout on every attempt is usually a path problem. A timeout that appears only during busy periods or after several quick reconnects can be the SSH service protecting itself.
That second case gets missed. SSH servers may limit unauthenticated connections, connections per source IP, or new connection rates. FileZilla can make this more visible because failed retries and multiple transfer connections may arrive close together. The port is open, the account is valid, and some attempts may still be silently dropped. That looks like a firewall problem from the client side.
Set FileZilla’s simultaneous transfers to 1, stop the retry loop for a minute, then make one fresh connection. If that works, inspect the server’s SSH connection limits, firewall rate rules, and any hosting-provider security controls. On OpenSSH, pay particular attention to MaxStartups and PerSourceMaxStartups if configured. A full connection queue or resource limit can cause similar behavior.
Use exact timestamps when checking the SSH journal or auth log. “No authentication failure” is not enough. You need to know whether sshd accepted the TCP connection, dropped it before authentication, or never saw it. @matrixcache9848 is right that credentials are irrelevant when the server sees nothing, but a silent pre-auth drop by sshd sits in the awkward middle: the route works, yet FileZilla still reports a timeout.
I would avoid raising FileZilla’s timeout as the first fix. A longer wait only hides the distinction and makes testing slower. Reduce connection concurrency, make a single controlled attempt, and compare that timestamp with the server log. If single attempts always work while batches fail, stop changing passwords and DNS records. You have a connection-limit problem, not an authentication mystery.
Before blaming the network, check that FileZilla isn’t sitting on a hidden host-key confirmation dialog behind the main window. It looks exactly like a stall, and @0xbit1’s advice to lower concurrency won’t touch it. Bring the window forward and see if it’s waiting on you, not the server.
That “connected, waiting for welcome message” line sounds like FileZilla is attempting FTP, not SFTP. Simply entering port 22 does not always switch the protocol, which is the bit that confused me at first. An FTP client pointed at an SSH port can connect at the TCP level and then sit waiting for an FTP greeting that will never arrive.
Create a fresh entry in Site Manager and explicitly choose “SFTP - SSH File Transfer Protocol.” Enter the same hostname and port PuTTY uses, then select the appropriate logon type and enter the username again. Don’t reuse the Quickconnect history for this test.
Once it is really using SFTP, the log should mention SSH details such as key exchange, the server host key, or authentication. If it still says it is waiting for a welcome message, the protocol selection is still wrong somewhere. If it switches to SSH messages but then stops, the earlier suggestions about a hidden host-key prompt, IPv6, or fzsftp.exe being blocked become relevant.
I’d verify this before changing firewall ports or server settings. The connection reaching port 22 only proves that something answered there. It does not prove FileZilla is speaking the right protocol to it.