Troubleshooting Outbound FTP

Use the failed operation and the Outbound Connections log to distinguish login failure from a listing or transfer failure. FTP uses separate control and data connections, so a successful login proves only part of the required network path.

Connection and Authentication Failures

Confirm the hostname, username, password, port, and SSL/TLS mode with the remote operator. Explicit FTPS normally uses port 21 and implicit FTPS port 990. If the supplied port is 22, confirm whether the service is SFTP instead. A customized port still needs the correct protocol and encryption mode.

For a rejected login, check the credential actually saved on the Remote Server or in the Credential Manager. Ask the remote operator whether the same attempt reached the service and whether its source address or account was refused.

Concurrent Connection Limits

Compare the service's account and address limits with the combined load from Mounts, Syncs, Automations, and other clients. Reduce Max connections when the destination rejects excess connections. Increasing it cannot increase the server's capacity.

A popular-counterparty limit identifies aggregate use from a shared route. Dedicated addresses can separate that traffic, but do not remove the remote service's own limits.

Timeout Issues

Identify whether the timeout occurs before login, during a listing, or during contents transfer. Compare its time with the remote server's connection and load records. The cause can be a network interruption, blocked data ports, changed service configuration, a capacity limit, or slow server responses.

Repeated concurrent retries can add load to an already constrained endpoint. Correct the network or capacity problem and test the affected operation with the same connection and an agreed sample.

Firewalls

Give the remote operator all source addresses for the selected route. Its rules must cover both the FTP control port and the complete passive data-port range. A rule allowing another client or a different Files.com route does not establish that this connection is allowed.

For Agent routing, those rules apply to the address seen from the Agent's network. Public Files.com source addresses do not describe the Agent-to-server connection.

Partial Connectivity

Login followed by failed listings or transfers points toward the data connection. A zero-byte destination after an attempted transfer can also indicate that only the control connection succeeded.

A private or invalid address in the server's PASV reply does not by itself explain failure: Files.com uses the control-connection host instead while retaining the advertised port. A permitted public address is used as advertised and can differ from the login host. Check the corresponding host's passive ports and NAT forwarding with the remote operator.

A successful listing tests only the port used for that listing. Another transfer can use a different port, so allow the server's full configured range. The passive connection reference explains address selection and the required firewall rules.

SSL Certificate Issues

For a certificate failure, confirm that the service presents a current certificate whose hostname matches and whose trust chain is valid. Ask its operator to correct the certificate or chain and confirm that the selected SSL mode matches the endpoint.

Allowing a non-matching or untrusted certificate bypasses identity checks. An encrypted connection with those checks disabled does not establish that Files.com reached the intended remote service.