How Does an FTP Server Work? A Technical Walkthrough

An FTP server is a piece of software running on a host that listens on TCP port 21 for incoming FTP client connections. It authenticates the connecting user, accepts FTP commands (login, directory navigation, upload, download), and exchanges file contents over a separate data connection. Popular open-source FTP servers — vsftpd, ProFTPD, FileZilla Server — power most self-hosted FTP infrastructure on the internet. This post walks through how an FTP server actually works at the protocol level, what the popular implementations are, and what most teams have replaced them with in 2026.

What an FTP server actually does

An FTP server does three jobs, in order:

1. Listens for incoming connections on TCP port 21 (and optionally additional ports for FTPS).
2. Authenticates connecting users against a local user database (or LDAP / PAM-backed alternatives).
3. Executes FTP commands that arrive on the control channel — listing directories, opening data connections, sending or receiving files, changing permissions.

The control channel and the data channel run on separate TCP connections — that's the dual-channel design that makes FTP both flexible and firewall-unfriendly. The server has to coordinate both channels, handle passive-mode handshakes, and apply per-user permission and chroot rules to every file operation.

In production, FTP servers also handle:

• TLS termination if FTPS is enabled (the server presents an X.509 certificate during the AUTH TLS handshake).
• Passive port range management — opening listening sockets in a configured range and advertising them to clients.
• Logging — every command, every file transfer, every failed authentication attempt.
• Concurrency — many clients connected simultaneously, each with their own session state.

How the protocol exchange actually works

The fastest way to see what an FTP server does is to connect with raw telnet and issue the commands yourself. The exchange below uses the public test server at ftptest.exavault.com.

Step 1: Open the control connection on port 21.

$ telnet ftptest.exavault.com 21
Trying 67.208.93.232...
Connected to ftptest.exavault.com.
Escape character is '^]'.
220 ProFTPD Server (EV) [67.208.93.232]

The server sent a 220 response with its identifier — in this case, the ProFTPD daemon. 220 means "ready for new user." That's the welcome banner.

Step 2: Authenticate with USER and PASS.

USER ftptest
331 Password required for ftptest
PASS *********
230 User ftptest logged in

331 means "user accepted, password needed." 230 means "login successful." Authentication is done; the session can now run file commands.

Step 3: Request passive mode for the data channel.

PASV
227 Entering Passive Mode (67,208,93,232,245,123)

The server has opened a listening socket on a high port and told us where to connect for the data channel. The port number is encoded as two bytes: 245 × 256 + 123 = 62843. (Yes, that's the actual encoding — it's RFC 959 from 1985 telling you to do byte arithmetic on the wire.)

Step 4: Open the data connection on the port the server advertised.

$ telnet ftptest.exavault.com 62843
Trying 67.208.93.232...
Connected to ftptest.exavault.com.

Now we have two TCP connections to the same server: control on 21, data on 62843.

Step 5: Issue a LIST command on the control channel.

LIST
150 Opening BINARY mode data connection for file list
226 Transfer complete

150 means "data connection about to open" and 226 means "transfer complete." But the actual directory listing isn't on the control channel — it's on the data channel. Switching to that telnet session:

drwxrwx---   2 ftptest  10002    0 Jul  1 17:37 .
drwxrwx---   2 ftptest  10002    0 Jul  1 17:37 ..
-rw-rw----   1 ftptest  10002   29 Jun 12 14:59 example.txt

That's the directory listing in Unix ls -l format. Every FTP transfer works this way: commands flow over the control channel, file bytes flow over a data channel that the server opens for each operation.

Step 6: Disconnect.

QUIT
221 Goodbye

221 is the server saying goodbye. Both TCP connections close.

This is what every FTP client (FileZilla, WinSCP, Cyberduck, the OS-bundled ftp command) does under the hood — just with a UI on top.

Popular open-source FTP server software

The four implementations powering most self-hosted FTP today:

• vsftpd — "Very Secure FTP Daemon." Default on most Linux distributions. Lightweight, fast, security-focused, easy to configure for read-only public-mirror use cases. Has been part of the Linux ecosystem since 2001 and is what powers many of the world's largest open-source mirror archives.
• ProFTPD — Heavier-weight, highly extensible via modules. Supports virtual users, per-user chroot, FTPS, SFTP (via mod_sftp), and a long list of authentication backends. The most flexible if your requirements are unusual; the configuration file is its own learning curve.
• FileZilla Server — Windows-friendly, ships with a graphical management UI. Common in shops where the FTP infrastructure runs on Windows alongside other services. Supports FTP and FTPS; for SFTP on Windows, most deployments pair it with OpenSSH or pick a different server.
• OpenSSH — Not an FTP server proper, but worth listing because its sftp-server subsystem is the universal SFTP implementation. Every Linux and macOS system ships with it; the SFTP server is one line of sshd_config away. For SFTP-only workloads, OpenSSH is usually all you need.

Other commercial options exist (Globalscape EFT Server, IBM Sterling, JSCAPE) but the open-source four dominate the long tail of self-hosted FTP infrastructure.

What a self-hosted FTP server doesn't give you

The protocol layer is the easy part. What an FTP server doesn't include, and what teams end up building around it:

• User onboarding flow. Adding a partner means provisioning a Unix or virtual user, generating credentials, configuring a chroot, and documenting it for the partner's IT contact. Scripts can do this; most shops eventually write them.
• Audit logging in a queryable form. The default FTP server logs are line-oriented text files; turning them into "show me every file partner X downloaded this month" usually means a log-aggregation layer (Loki, Splunk, an ELK stack) on top.
• Key and credential rotation. Rotating an SFTP key on a per-partner basis is a manual operation by default; rotating an FTPS certificate breaks every connecting client until they update.
• MFA and SSO. Standard FTP and SFTP don't support multi-factor or SSO natively. Adding them means a third-party PAM module or a different layer in front.
• Health monitoring. "Is the FTP server actually accepting connections?" is a question with no built-in answer. Health checks are something you write.
• Compliance evidence. SOC 2, HIPAA, PCI — every auditor wants documented controls. Owning the FTP server means owning the compliance scope.

These costs are why most teams that started with self-hosted FTP eventually moved to managed platforms that handle the operational surface as a service.

The modern way: a managed file-transfer platform

Files.com is the File Orchestration Platform we'd recommend for any team running FTP-shaped workflows in 2026. The platform exposes FTP, FTPS, SFTP, and WebDAV on their standard ports on a subdomain Files.com provisions — your trading partners connect with whatever FTP client they already have, and the server side is fully managed:

• The protocol layer Files.com runs. Patching, cipher hygiene, passive-port management, TLS certificate auto-renewal — none of it is your scope.
• User onboarding through the admin UI or REST API. Add a partner in 30 seconds; rotate or revoke credentials in one click.
• Audit logging on every operation, queryable in the dashboard. Per-file, per-user, immutable trail. Drops directly into SOC 2 evidence collection.
• MFA, SSO with SAML/SCIM, IP allowlisting — enterprise security posture out of the box.
• SOC 2 Type II and HIPAA-BAA pre-built. Files.com owns the compliance scope; you inherit the posture.
• Modern features the protocol never had. REST API, automation workflows, AS2 partner messaging, share links with passwords and expiry, a browser-based file manager.

Start a free Files.com trial — no credit card, provisioned in about 10 minutes. The "how do I set up an FTP server" question gets replaced by "what protocols do my partners want to use."

For the narrow set of teams that must run file-transfer infrastructure inside their own datacenter — air-gapped environments, strict data-residency mandates, regulated workloads that prohibit multi-tenant cloud — the free ExaVault on-premise appliance ships an FTP server (plus FTPS, SFTP, WebDAV) as a self-hosted VM image with the operational surface still managed by the vendor.

FAQ

What is an FTP server in simple terms?

An FTP server is a piece of software that lets other computers connect over the network, log in, and upload or download files. Think of it as the file-cabinet half of a file-cabinet/file-cabinet-key arrangement — the server holds the files; clients connect with credentials to put files in or take files out.

What port does an FTP server use?

Port 21 for the control channel (login, commands), plus either port 20 (active mode) or a range of high ports (passive mode, typically 49152–65535 by default) for the data channel. FTPS adds port 990 for implicit-TLS deployments. SFTP servers listen on port 22, the same as SSH. See our FTP ports deep-dive for the firewall implications.

How do I set up an FTP server?

On a Linux server, apt install vsftpd (Debian/Ubuntu) or dnf install vsftpd (RHEL/Fedora) installs the daemon. The default configuration enables anonymous read-only access; the /etc/vsftpd.conf file (or /etc/vsftpd/vsftpd.conf) controls everything else — user authentication, chroot, passive port range, TLS settings. For SFTP specifically, enable the OpenSSH sftp-server subsystem in sshd_config; no separate FTP server needed.

For most production deployments, the self-hosted setup is the easy part — the harder part is everything after (user management, audit logging, compliance, monitoring). A managed platform skips that work.

What's the difference between an FTP server and an SFTP server?

An FTP server speaks the original FTP protocol on port 21 — cleartext by default, dual-channel design. An SFTP server speaks SSH File Transfer Protocol on port 22 — encrypted by default, single-channel, supports key-based authentication. They're different protocols; a client built for one cannot connect to the other. Most managed-file-transfer platforms (including Files.com) run both on the same backend storage so clients can use either.

How does an FTP server authenticate users?

The standard protocol supports two models: anonymous FTP (any user, any password — convention is to send an email address) and password authentication. The server checks the username and password against its local user database (Unix accounts, virtual user files, LDAP, PAM, or a custom auth backend depending on the server software). FTPS adds TLS to encrypt the password in transit but uses the same password model. SFTP servers additionally support SSH public-key authentication.

Can multiple users connect to an FTP server at the same time?

Yes. Every FTP server supports concurrent connections; the limit depends on the server configuration (MaxClients in ProFTPD, max_clients in vsftpd, similar settings in others) and the host's resources. Typical defaults are 50–500 concurrent connections; well-tuned servers handle thousands. Each connection is a separate session with its own authentication state, directory context, and data-channel handshake.

What's the difference between an FTP server and a file server?

An FTP server specifically speaks the FTP protocol and is accessed over the network with FTP clients. A general file server is a broader category — it might serve files over SMB/CIFS (the Windows file-sharing protocol), NFS (the Unix equivalent), HTTP, or several protocols at once. FTP servers are file servers, but file servers don't have to be FTP servers.