“FTP proxy” can describe a gateway that speaks FTP itself. Connecting to it is different from asking an HTTP proxy for CONNECT or asking a SOCKS server to open a TCP destination.

The gateway needs the target host and account, and it may need its own login first. Products express that conversation in different ways:

ArrangementTypical command shape
Target encoded in a usernameUSER target-user@target-host
Separate gateway loginGateway USER/PASS, followed by the target login
Explicit destination commandSITE target-host or OPEN target-host, then the required login

These are families of conventions, not one standard sequence to send to every gateway. Select the method documented by the administrator and supported by the client.

Keep both accounts visible in the setup

The target FTP password and the gateway password can be different. Some gateways combine them in one USER/PASS representation; others require separate exchanges. Putting every value in one string cannot reproduce a client that must send additional commands.

This explains a useful boundary in legacy FtpWebRequest code. An ordinary FTP connection to the gateway, with a gateway-specific username, can fit some USER/PASS arrangements. A gateway requiring a separate SITE or OPEN conversation needs a client that actually supports that flow. The WebRequest Proxy property is another interface again.

WinSCP, for example, exposes distinct FTP proxy login methods rather than treating all gateways as one host field. Its numeric raw-setting values belong to its documented API; use the method name and intended conversation when reviewing a configuration.

After login, file transfer still needs its FTP data connection and the chosen TLS mode. A successful control-channel login is the beginning of that route, not proof that every data transfer is already permitted.

Erthyglow kevrennek