Direct Routing

Direct Routing automatically transfers file contents between your client and supported cloud storage, without relaying those contents through Files.com's network. There is no Direct Routing switch to enable. Files.com selects the transfer path from the storage connection, authentication method, client, operation, and required processing.

Avoiding the relay removes an extra network hop and can improve transfer speed. The directly transferred contents do not count toward Files.com Transfer Usage. This does not remove the storage provider's own charges or other Files.com usage measures.

Files.com still authenticates the user and authorizes the file operation. The client receives a temporary transfer URL for the authorized work; users do not need your storage account's long-lived credentials. Direct Routing changes the path carrying the contents, while the Mount continues to expose the same remote files under Files.com permissions.

Eligible Storage Connections

Upload and download support differ. The following table describes the supported directions for client transfers; the client and processing conditions below also apply.

Azure Files and the content collaboration connectors use Files.com's network for their cloud transfers. The Files.com Agent's Direct Transfers is a separate capability with its own configuration and network requirements.

Clients and Operations

The CLI App, Desktop App, and official SDKs use eligible direct transfers automatically. Keep clients up to date. For the additional S3-compatible providers, direct uploads require CLI 2.15.376, Desktop App 6.0.2692, or Go SDK 3.3.177 or later. Earlier versions use Files.com's network.

Browser transfers need to be considered separately. Amazon S3 can receive direct uploads from the web interface. Web uploads to the additional S3-compatible providers listed together in the table relay through Files.com. A single-file download can use a direct URL to supported storage, including when started in the web interface. Previews, generated ZIP downloads, and other operations that process contents are separate operations with their own data paths.

Connections through SFTP, FTP/FTPS, WebDAV, AS2, or the Files.com S3-Compatible Endpoint carry contents through Files.com's network. A client using one of those protocols does not gain Direct Routing merely because its destination folder is backed by S3 or another eligible provider. Likewise, a Sync or Automation performs work between its configured locations; it is not a direct transfer between your workstation and the provider.

Buffering, Processing, and Network Routing

Buffered Uploads first receives the complete file into Files.com Native Storage, then forwards it to the remote destination. That upload uses Files.com's network. GPG processing, Auto Unzip, and Malware Scanning on a mount require staged uploads even when optional buffering is set to Never. Required processing takes precedence over a provider's direct-upload capability.

Connection routing also matters. Downloads configured to use Files.com's dedicated outbound addresses relay through Files.com so the provider sees those source addresses. Operations routed through an Agent use the Agent's network to reach the provider. A direct client transfer instead reaches the storage endpoint from the client's network. Selecting dedicated IP addresses for a Remote Server does not make a direct upload originate from those addresses. The Remote Server routing reference explains the addresses used by connections from Files.com.

For a provider protected by network restrictions, account for both the connection Files.com makes and any direct client transfers. A successful Browse action from Files.com does not establish that a user's workstation can reach the storage endpoint. Review the actual operation, client version, buffering and processing settings, and selected route when investigating unexpected speed or transfer usage.