Investigate an FTP Listing Failure After a Successful WinSCP Login
A successful FTP login proves less than it may appear to. FTP uses a control connection for commands and a separate data connection for directory listings and file content. A failure at the second stage can leave authentication working while the folder view never finishes loading.
Record the server name, the selected protocol and the exact action that fails. Keep FTP separate from SFTP in the report; similar names do not mean the two protocols establish their data paths in the same way.
Identify which side opens the data connection
WinSCP defaults to passive FTP mode. In passive mode, the client obtains the server's data address and port and opens that connection. In active mode, the client listens for an incoming data connection from the server. A firewall or translated network path can affect these arrangements differently.
Check the site's Passive mode setting and retain its original value. Do not cycle through unrelated settings or disable a firewall simply because the password was accepted. Ask the server administrator which mode and data-port arrangement the service is intended to support.
For passive FTP behind server-side NAT, the advertised address and configured data-port range must be usable from the client. WinSCP can detect an unroutable advertised address and use the control-connection host address instead; its FTP settings also expose Force IP address for passive mode connections. Treat that as a specific address-handling option, not a universal fix for every timeout.
Give the administrator a reproducible boundary
Repeat one harmless directory listing and record the time, error text and whether login completed first. If a session log is available, retain the relevant negotiation and failure privately, reviewing identifying details before sharing it through the agreed support route.
A useful comparison changes only the administrator's identified setting and repeats the same listing. Once that works, test a small authorised file transfer separately. Listing success and transferring the intended content are related but distinct acceptance checks.
If a passive-address correction fixes the listing, document the corrected setting and the network context. If it does not, preserve that result rather than widening access indiscriminately. The evidence should locate the failing data path, not turn a successful login into an unsupported claim that the whole FTP service is healthy.
Sources: WinSCP documentation, WinSCP documentation.