WinSCP FTPS Logs In Through the Proxy but Cannot List Files

An FTPS login proves that the control connection worked. A directory listing needs another connection, so a proxy can permit the login while blocking the next step.

For an explicit FTPS server, configure the control route and passive mode with WinSCP .NET:

var options = new WinSCP.SessionOptions
{
    Protocol = WinSCP.Protocol.Ftp,
    HostName = "ftp.example.net",
    PortNumber = 21,
    UserName = ftpUser,
    Password = ftpPassword,
    FtpSecure = WinSCP.FtpSecure.Explicit,
    FtpMode = WinSCP.FtpMode.Passive
};

options.AddRawSettings("ProxyMethod", "3");
options.AddRawSettings("ProxyHost", "proxy.example.net");
options.AddRawSettings("ProxyPort", "8080");

ProxyMethod value 3 selects HTTP CONNECT. Open these options through the application's normal WinSCP Session lifecycle, and add ProxyUsername and ProxyPassword raw settings when the intermediary requires authentication.

Follow the listing failure

Inspect the session log for the negotiated passive data endpoint and its connection failure. The proxy must allow that destination and port as well as the FTP control endpoint. A rule allowing CONNECT only to the control port can therefore accept the login and reject the listing.

Changing the control port alone cannot fix a blocked data path. Use the logged data endpoint when checking the network policy.

This example starts explicit FTPS on port 21 and negotiates TLS. For an implicit FTPS endpoint, use the corresponding FtpSecure mode and server port. In either case, use the server's actual TLS hostname and certificate-validation configuration.