- Docs
- Networking & Performance
- Connecting to Files.com
Connecting to Files.com
Files.com is a large, global cloud platform that supports secure connections from a wide range of networks and systems. This page serves as a general reference for all connection details, including IP ranges, ports, and endpoint information that may be useful when configuring network policies or troubleshooting connectivity.
While some organizations may choose to whitelist Files.com traffic in their firewall, doing so is not always required. Use this page to understand how Files.com connects, which IPs are involved, and which ports and endpoints support each protocol.
Files.com IP Addresses
Files.com operates on a dedicated IP address range and a transitional list of addresses hosted on Amazon Web Services (AWS). Some environments may need to reference these IPs when applying firewall or network filtering rules.
Files.com IP Address Simplification and Transition
Files.com has acquired a contiguous, dedicated IP address range and is transitioning to exclusive use of that range for all inbound and outbound connections.
This transition will complete on March 2, 2026. After that date, a single firewall rule covering the Files.com IP range will be sufficient for any environment that restricts network traffic by IP.
Until that transition is complete, Files.com continues to use both its owned IP range and a set of AWS-hosted IPs that are exclusively under Files.com control. Make sure all listed IPs are allowed, as Files.com actively uses them as part of standard operations.
Files.com Owned IP Range
Files.com owns the IP block 198.72.80.0/20, which includes all addresses from 198.72.80.0 through 198.72.95.255.
Non-Owned IP Addresses (Used During Transition)
The following IP addresses are owned by Amazon Web Services but are used exclusively by Files.com. They include addresses for all operational regions and service types. This list will remain stable until the March 2, 2026 transition is complete.
Until March 2, 2026, whitelist both the Files.com owned IP range and the AWS IP list below. After that date, only the owned range will be needed.
13.115.185.197
13.211.6.58
13.211.8.8
13.228.110.5
13.230.174.211
13.251.23.79
13.251.75.92
18.130.82.3
18.130.85.21
18.184.31.111
18.196.218.237
18.196.249.148
18.205.187.185
18.210.222.34
3.124.213.47
34.193.60.221
34.194.175.247
34.204.145.250
34.204.150.23
34.204.153.236
34.204.236.250
34.204.250.40
34.205.137.182
34.206.140.166
34.246.103.210
34.251.118.53
34.252.200.237
35.157.95.231
35.176.125.40
35.178.122.29
35.178.154.72
35.178.42.15
35.178.42.158
35.182.68.20
46.51.239.135
52.17.96.203
52.18.87.39
52.20.236.84
52.215.35.55
52.221.157.129
52.23.22.134
52.28.101.76
52.29.176.178
52.44.29.99
52.56.167.16
52.56.197.159
52.58.79.145
52.60.101.109
52.60.113.8
52.60.129.247
52.60.153.17
52.60.214.201
52.60.239.159
52.60.245.89
52.62.59.186
52.64.150.164
52.64.199.91
52.64.2.88
52.64.251.226
52.64.6.120
52.68.30.197
52.68.4.44
52.74.166.120
52.74.188.115
52.77.142.208
52.77.8.56
52.8.210.89
52.9.227.24
54.193.65.189
54.193.69.198
54.193.69.200
54.193.69.72
54.207.27.239
54.208.20.30
54.208.63.151
54.209.222.205
54.209.231.233
54.209.231.99
54.209.242.244
54.209.246.217
54.209.91.52
54.232.253.47
54.64.240.152
54.95.179.0
54.95.60.23
99.79.110.182
Former ExaVault Customers Using The ExaVault Host Key
Sites that were migrated from ExaVault and still use the legacy host key may also need to allow the additional IPs listed below. These apply in addition to the addresses above.
13.228.186.243
13.238.24.104
13.42.187.250
13.43.144.19
13.43.252.114
15.156.171.39
15.157.18.35
15.222.152.139
15.223.99.121
18.130.100.59
18.140.210.180
18.141.46.121
18.142.81.195
18.169.205.250
18.179.140.197
18.192.220.219
18.205.170.87
18.205.8.81
18.233.238.114
3.1.164.240
3.10.244.187
3.104.7.236
3.105.246.2
3.105.7.234
3.11.144.56
3.11.99.9
3.115.57.224
3.217.82.30
3.227.183.71
3.232.229.87
3.24.7.224
3.64.69.163
3.69.89.96
3.71.218.186
3.98.119.91
3.98.231.156
3.98.73.0
34.192.34.71
34.202.116.48
34.202.23.159
34.202.28.186
34.231.28.146
34.233.32.85
35.157.224.212
35.158.202.135
35.171.168.150
35.174.249.23
44.197.126.42
44.205.164.56
44.205.181.212
44.205.218.209
44.205.47.95
47.128.84.237
52.195.51.46
52.198.164.219
52.58.177.36
52.58.234.163
52.60.180.89
52.62.116.80
52.63.177.193
52.69.163.199
54.175.70.146
54.199.165.62
54.205.227.156
54.250.51.79
54.254.174.4
54.254.184.120
54.79.148.165
54.82.79.68
54.84.38.86
54.86.1.128
57.180.72.80
Files.com Endpoints and Regional URLs
When you connect to Files.com, you will encounter URLs or endpoints such as https://app-us-east-1.files.com. These endpoints represent regional Files.com clusters that manage uploads, downloads, and integrations efficiently across our global infrastructure. Each regional cluster routes data to the closest Files.com service region to minimize latency, improve transfer performance, and ensure the highest possible reliability for your site’s file operations.
These endpoints appear in a variety of contexts, including web browsers, the Desktop App, and network logs during file operations or automations. Exact subdomain names, such as app-us-east-1.files.com or app-eu-west-1.files.com, change periodically as part of Files.com’s ongoing infrastructure updates.
Any domain ending in files.com is a trusted, Files.com-controlled endpoint that operates under the same encryption and compliance standards as your primary site.
DNS and Hostname Resolution
All Files.com connections rely on standard DNS resolution to translate hostnames such as app-us-east-1.files.com, your Custom Domain, or other service-specific endpoints into their corresponding IP addresses. Configure your network to allow outbound DNS queries so client systems can resolve these hostnames successfully. Because Files.com endpoints are load-balanced and designed for global scalability, they use DNS-based routing to direct traffic to the most efficient application cluster. Whenever possible, use DNS names rather than hard-coded IP addresses. Relying on DNS ensures uninterrupted access even when Files.com updates or expands its infrastructure.
Organizations that use network security controls based on domain filtering must configure those controls to allow access to all *.files.com hostnames. This ensures that user connections, automated tasks, and background processes can communicate securely with the Files.com platform without disruption.
Why Regional Endpoints Exist
Files.com uses regional application clusters to deliver high performance, global fault tolerance, and operational reliability. Each regional cluster manages file operations, API requests, and integrations within its geographic area. This distributed architecture allows the platform to route traffic efficiently, isolate workloads, and expand capacity without downtime. By routing data through the nearest cluster, Files.com minimizes latency and accelerates transfers while maintaining encryption, compliance, and data integrity.
Regionalization also separates user-facing web traffic from background compute activity. This design enables Files.com to maintain fast, responsive web sessions while executing large-scale background processes independently. The architecture allows Files.com to scale globally and perform routine infrastructure updates without impacting connected customers.
Custom Domain Behavior
When your organization uses a Custom Domain, such as https://files.yourcompany.com, user-facing web traffic flows through that domain. However, certain operations rely on regional *.files.com endpoints to perform background tasks that occur outside the interactive user session. This routing is intentional and necessary to maintain performance, reliability, and secure integration with external systems.
Operations such as uploads to Remote Mounts, third-party integrations, and background automations are processed by regional application clusters, such as https://app-us-east-1.files.com or https://app-eu-west-1.files.com. These clusters handle encryption and decryption workflows, file transfer orchestration, automation scheduling, event handling, and data synchronization between systems. By processing these activities on the regional infrastructure, Files.com ensures that jobs execute as close as possible to their associated storage location, which improves efficiency and consistency across the platform. This separation of compute activity from user traffic allows Files.com to deliver predictable performance, even under heavy workloads.
Network Access Requirements for Files.com Services
Administrators and firewall teams must ensure that their networks can reach all necessary Files.com endpoints to maintain full functionality. The Web Application, Desktop App, and Mobile App all communicate with both the Custom Domain and the nearest Files.com regional cluster for authentication, data transfers, and background synchronization. Remote Mounts and third-party integrations, including connections to AWS S3, Azure Blob Storage, and Google Cloud Storage, depend on regional endpoints to manage cross-system transfers. Automations, API workflows, and event-driven processes also communicate with these regional clusters to coordinate tasks and maintain service reliability.
Protocol-based services such as SFTP, FTP/FTPS, and WebDAV operate through their own dedicated protocol endpoints and do not connect directly to Files.com’s storage endpoints or web application clusters. Each service relies on distinct network paths to ensure efficiency and compliance with security and performance standards. Blocking access to regional endpoints can interrupt uploads, background tasks, and integration workflows, even when your Custom Domain remains reachable.
Ports
If your network restricts inbound or outbound access by port, refer to the table below when configuring connectivity. Each protocol uses specific ports for control and data channels.
| Protocol / Service | Port(s) | Direction | Description |
|---|---|---|---|
| HTTPS / API / Web Interface | 443 | Inbound | Used by the Files.com web app, Desktop App, CLI, SDKs, and REST API |
| FTP(S) (Control) | 21 | Inbound | Standard FTP command channel |
| FTP(S) (Data) | 40000–50000 | Inbound | FTP data passive channel range |
| FTPS (Implicit) | 990 | Inbound | Implicit FTPS control channel |
| FTPS (Alternate) | 3021 | Inbound | Alternate explicit FTPS command port |
| FTPS (Implicit Alternate) | 3990 | Inbound | Alternate implicit FTPS command port |
| SFTP | 22 | Inbound | Secure File Transfer Protocol (SFTP) command and data channel |
| SFTP (Alternate) | 3022 | Inbound | Alternate SFTP port |
| AS2 (HTTP / HTTPS) | 443 | Inbound | Used for AS2 connections |
| WebDAV | 443 | Inbound | WebDAV access via HTTPS |
| Outbound Connections (all protocols) | Dynamic | Outbound | Used by Files.com for Remote Servers, SMTP, LDAP, and Webhooks |
If your firewall inspects or limits outbound connections, configure it to allow traffic for the ports listed above.
Whitelisting Files.com in Your Firewall
If your organization enforces network access restrictions by IP or port, you may need to whitelist Files.com traffic to allow successful connections.
Use the IP ranges and port references in this guide to configure your firewall or security gateway.
- Preferred method: Allow traffic to the entire Files.com owned range (
198.72.80.0/20) and to*.files.comdomains. - During the transition period: Also allow the AWS-hosted IP addresses listed above until March 2, 2026.
- After the transition: Only the owned IP range will be required.
Most customers do not need to manually whitelist Files.com. These settings apply only to organizations with restrictive network egress or ingress controls.
If your organization blocks all online file-sharing services by default, you may also need to whitelist Files.com Storage URLs to ensure access to stored files and uploads from the Files.com backend.
Outbound Connections from Files.com
Files.com uses IP addresses from both its owned range and the AWS transition list for all outbound connections, including Webhooks, SMTP email delivery, Single-Sign-On/LDAP connections, Sync and Remote Mount features.
If your site uses dedicated IP addresses, certain features, such as Remote Servers, Webhooks, and Custom SMTP, can be configured to use those dedicated addresses for outbound traffic. We recommend leaving outbound connections on the shared pool unless a specific counterparty requires fixed source IPs for firewall reasons.