A SOCKS Route for Commons Net’s FTPSClient

When a SOCKS intermediary is available, Commons Net’s FTPSClient can use the inherited socket-proxy interface. Keep the FTPS server as the connection destination:

var client = new org.apache.commons.net.ftp.FTPSClient(false);
client.setProxy(new java.net.Proxy(
    java.net.Proxy.Type.SOCKS,
    new java.net.InetSocketAddress("proxy.example", 1080)));
client.setTrustManager(null);
client.setEndpointCheckingEnabled(true);
client.setConnectTimeout(10000);
client.connect("ftps.example", 21);

This starts an explicit-FTPS connection. The application still owns login, data-protection negotiation, transfer handling and disconnection. The null trust-manager setting selects the JVM’s default trust managers rather than Commons Net’s date-only certificate check. Use the intended trust store and the server’s certificate hostname.

For passive transfers, the current FTPSClient implementation creates its data socket through the configured proxy too, then adds the TLS layer. After login, use passive mode and negotiate the required protected data channel through the normal FTPS API. A successful control connection does not complete that work; the passive data connection remains a separate path.

The code assumes a SOCKS service without an additional account. Authentication support needs separate review for the chosen Java runtime and deployment.

This is not the HTTP CONNECT interface of FTPHTTPClient. That sibling handles ordinary FTP over an HTTP tunnel; changing its port does not add FTPS. If the network permits only an HTTP proxy, select an FTPS implementation or maintained adaptation that supports CONNECT on both control and data paths.

Retain the proxy configuration for the client lifecycle, and review it before reconnecting a reused instance: FTPS disconnection resets socket factories. Do not replace certificate checks with a trust-all manager to make the route appear successful.