There is one FTP symptom so common it deserves its own page: you connect, you authenticate successfully, and then the directory listing spins forever and times out. Your credentials are right. The server is up. Nothing happens.
This is the FTP data connection failing, and understanding why takes about five minutes.
Two connections, one problem
FTP uses a control connection for commands and a separate data connection for file contents and directory listings. Logging in only uses the control connection — which is why authentication succeeds. Listing a folder needs the data connection, which is where things break.
The question that decides everything is: who opens the data connection?
Active mode: the server connects to you
In active mode (the original design), your client sends a PORT command telling the server “I am listening on this address and this port, connect to me”. The server then opens a new inbound connection from its port 20 back to your Mac.
> PORT 192,168,1,40,197,140
< 200 PORT command successful
> LIST
< 150 Opening data connection
← server now dials back to 192.168.1.40:50572
In 1971 that was fine. In 2026 it fails almost everywhere, for two reasons that apply to virtually every home and office connection:
- You are behind NAT. The address your client advertises is a private one —
192.168.x.xor10.x.x.x. The server cannot route to it. It is not a reachable destination on the internet. - You are behind a firewall. Even with a public IP, an unsolicited inbound connection to a high port is exactly what a firewall exists to drop.
Active mode only works when your machine is directly reachable from the server, which for a laptop on Wi-Fi is essentially never.
Passive mode: you connect to the server
Passive mode inverts it. Your client sends PASV (or EPSV, the IPv6-capable version), and the server answers with an address and port it has opened. Your client then makes a second outbound connection to it.
> PASV
< 227 Entering Passive Mode (203,0,113,10,195,80)
> LIST
< 150 Opening data connection
→ client dials out to 203.0.113.10:50000
Outbound connections sail through NAT and through nearly every firewall, because that is the normal direction of traffic. This is why passive mode is the default in every sane modern client and why it is almost always the answer.
Reading that address format
The numbers in the 227 reply are the trap. (203,0,113,10,195,80) is six comma-separated bytes: the first four are the IP address (203.0.113.10), and the last two are the port, encoded as high × 256 + low. So 195,80 means 195 × 256 + 80 = port 50000.
This matters because of a classic misconfiguration: a server behind its own NAT that reports its private address in the 227 reply. Your client dutifully tries to connect to 10.0.0.5:50000, which on your network is either nothing or the wrong machine. The fix is on the server (MasqueradeAddress in ProFTPD, pasv_address in vsftpd), but a good client can also detect the mismatch and reuse the address it is already connected to.
Why FTPS makes it worse
A firewall doing FTP connection tracking watches the control channel, reads the PASV reply, and pre-authorises the data port. That inspection is what makes FTP work at all in many networks.
Encrypt the control channel with FTPS and the firewall goes blind. It can no longer read the reply, so it cannot open the port. The result is the exact symptom this page opened with — authentication fine, listing dead — except now it happens even in passive mode.
The server-side fix is to define a narrow passive port range and open it in the firewall:
# vsftpd.conf
pasv_enable=YES
pasv_min_port=50000
pasv_max_port=50100
pasv_address=203.0.113.10
The protocol that sidesteps all of this
SFTP has one connection. Commands, listings and file data are multiplexed inside a single SSH channel on port 22. There is no second connection to be blocked, no active or passive mode, no port range to configure, no NAT address to get wrong.
If you find yourself debugging passive port ranges and your server has SSH, the fastest fix available is to stop using FTP.
Step by step
- Confirm the symptom — login succeeds,
LISTorMLSDhangs, then times out with a 425 or 426. That is the data connection. - Make sure you are in passive mode — it is the default in Upstream and in most clients, but a site imported from an old configuration may have active mode saved.
- Read the 227 reply in the protocol log — if the address it returns is a private one (10.x, 172.16–31.x, 192.168.x) while you connected to a public host, the server is misconfigured.
- Check the passive port range — the server needs a defined range and the firewall in front of it needs that range open. This is the usual cause on self-hosted servers.
- Try SFTP instead — if the host offers SSH, the entire class of problem disappears.
Questions people ask
Should I use active or passive FTP?
Passive, in nearly all cases. Active mode requires the server to open an inbound connection to your machine, which fails behind NAT and firewalls. Use active only on a local network where you know your Mac is directly reachable.
Why does my FTP work at home but not at the office?
Corporate firewalls tend to be stricter about the data connection, and some inspect or block FTP entirely. If passive mode does not help, the network is filtering it and SFTP over port 22 is the usual workaround.
What is EPSV?
Extended Passive Mode, from RFC 2428. It does the same job as PASV but returns only a port number rather than an encoded address, which makes it work with IPv6 and immune to the private-address mistake. Clients try EPSV first and fall back to PASV.
Why do I get “425 Can’t open data connection”?
The client could not establish the data connection at all — usually a blocked port, a wrong passive address, or active mode being attempted from behind NAT. See the FTP error code reference.
Does passive mode affect transfer speed?
No. The direction the data connection is opened has no bearing on throughput once it is established.