FTP 421 Too Many Connections from This IP: Causes and Fixes

Why does the FTP server return “421 Too Many Connections from this IP”?

421 Too Many Connections from this IP means that the FTP server has refused another session from the source IP because a configured limit has been reached. FTP reply code 421 indicates that the service is temporarily unable to handle the new connection, while the accompanying text explains the reason selected by the specific FTP server.

In the client log, it may look like this:

Response: 421 Too many connections from this IP
Error: Could not connect to server

The wording varies between FTP servers and hosting panels. You may see 421 Too many connections, 421 Too many connections from your IP, or something similar. The diagnostic meaning is the same: before changing the password, DNS settings, or file permissions, check the FTP sessions that are already open.

The restriction may apply at several levels:

• maximum number of clients for the entire FTP service;
• maximum number of connections from one IP address;
• maximum number of sessions for one FTP user;
• a combination of several limits at the same time.

This is different from an authentication error. If the server returns 530 Login incorrect, check the username, password, and login permissions. With Connection refused, an FTP session is not established at all: the port may be closed or the FTP daemon may not be listening on it. With a timeout, troubleshooting moves toward the network, firewall, routing, and server availability.

If the browser also reports ERR_TOO_MANY_REDIRECTS, do not mix the two symptoms. Redirect loops require separate troubleshooting, including the web server configuration and, for WordPress, plugins that may create redirect loops.

Stop additional transfers and create one new FTP connection. If it succeeds without changing the username or password, the problem is related to the number of sessions or a connection limit rather than authentication.

How many FTP connections does FileZilla or another FTP client actually open?

One open FileZilla window does not mean one FTP session. The client may keep one connection for directory navigation while creating additional sessions for parallel file transfers.

The interface may show one configured site, while the server sees several active control sessions: one transfer is still running, another has started, more files are queued, and failed transfers are being retried. With a low per-IP limit, this may already be enough to trigger 421.

How parallel transfers increase the number of FTP sessions

The problem becomes especially noticeable when uploading websites with many small files. One large archive may use a single working session for a long time without hitting a limit. A directory containing thousands of PHP, CSS, JS, and image files makes the FTP client use its queue and parallel transfer features much more actively.

Additional connections may appear when the user:

• uploads several files at the same time;
• downloads other files simultaneously;
• navigates through remote directories;
• retries failed queue items;
• opens the same FTP site in another copy of the client;
• leaves automatic reconnection enabled after a network interruption.

Do not try to derive a universal connection count from the number of FileZilla windows. The behavior depends on the client, its settings, and current operations. FTP data connections and the FTP daemon's internal client counter are not necessarily the same thing either.

How to test parallel transfer limits in FileZilla

For troubleshooting, open the FileZilla transfer settings and temporarily reduce the maximum number of simultaneous transfers to 1–2. Menu names and locations may vary slightly between versions, so look for the Transfers section and the simultaneous transfers setting.

1. Stop the current transfer queue.
2. Reduce parallel transfers to 1–2.
3. Disconnect from the FTP server.
4. Connect again.
5. Transfer one file.
6. Then add a small queue and repeat the test.

If 421 disappears with one or two transfers and returns when the previous parallelism is restored, adjust the client first. The server limit is behaving predictably; the remaining question is whether that level of parallelism is actually necessary.

How to quickly close extra and stale FTP sessions

If the limit has already been reached, reducing future transfers may not help immediately because old FTP sessions can still occupy available slots. First stop new connections, then check whether existing sessions are being released.

What to do on the computer

1. Stop the active file queue.
2. Disconnect from the FTP server using the client controls.
3. Close FileZilla, WinSCP, or another FTP client.
4. Check whether the same server is open in another copy of the application.
5. Close IDE, deployment, and backup tools that may use this FTP account.
6. After old sessions clear, perform one new connection attempt.

The server does not have to remove a broken session immediately. Timeouts are controlled by the FTP daemon configuration, and after a network interruption or an abnormal client shutdown, the TCP connection may remain in an intermediate state for some time.

How to identify the FTP daemon running on a VPS

If you have root access, start by checking the service:

systemctl status proftpd
systemctl status pure-ftpd

If you have selected the correct service, the most important line usually looks similar to:

Active: active (running)

If the FTP service is inactive or failed, this is no longer a normal connection-limit scenario. First determine why the daemon is not running.

If you do not know the systemd unit name, find the process:

ps -eo pid,args | grep -E '[p]roftpd|[p]ure-ftpd'

A line containing the proftpd or pure-ftpd executable confirms which daemon is actually running. At that point, FileZilla is no longer the main focus. Check the server.

How to view real FTP connections from one IP

For an initial check of TCP control connections on the standard FTP port 21, use ss:

ss -tnp state established | grep ':21 '

Depending on the version of ss and its output format, the filter may need adjustment. If FTP uses a non-standard port, replace 21 with the actual control port. Implicit FTPS often uses a different port, while explicit FTPS usually starts over the regular FTP control port.

A simplified example may look like this:

ESTAB 0 0 203.0.113.10:21 198.51.100.25:54321
ESTAB 0 0 203.0.113.10:21 198.51.100.25:54322
ESTAB 0 0 203.0.113.10:21 198.51.100.25:54323

The server address is the same, the remote IP is the same, but the client source ports differ. This output shows at least three established TCP control connections from 198.51.100.25.

What TCP states mean when troubleshooting FTP

• ESTAB — the TCP connection is established and active. This is the most relevant state when checking occupied FTP control connections.
• CLOSE-WAIT — the remote side has closed the connection, but the local process has not completed its side of the shutdown. If many of these remain for a long time, inspect the daemon behavior.
• FIN-WAIT-1 / FIN-WAIT-2 — the connection is already closing and going through TCP shutdown.
• TIME-WAIT — the TCP connection is already closed, but the kernel temporarily keeps the state. Do not automatically count every TIME-WAIT entry as an active FTP login.

Take two snapshots. The first while the error is reproducible, and the second after stopping the queue and closing FileZilla. If the three ESTAB connections disappear, they were tied to the client sessions. If they remain or new ones appear, continue troubleshooting.

Restarting the FTP service may clear sessions, but it is an administrative action, not the first diagnostic test. A restart will interrupt valid transfers from other users and may also destroy the evidence you wanted to inspect.

Why does the error remain after the FTP client is closed?

Closing FileZilla does not prove that the server no longer sees connections from your IP. A broken TCP session may still be shutting down, another process may continue to connect, and automatic reconnect may create a new session almost immediately after the previous one disappears.

How to distinguish a stale session from a new reconnect

Record the remote IP and source port of active connections before closing FileZilla. Then close the client and run ss again. If the old connections disappear but new ones from the same IP appear almost immediately with different source ports, something is reconnecting.

For example, before closing the client:

198.51.100.25:54321
198.51.100.25:54322

After closing it, those disappear and are replaced by:

198.51.100.25:55107
198.51.100.25:55108

This no longer looks like two old sessions simply waiting for a timeout. Something is creating new TCP connections. The source may be FileZilla reconnecting automatically, another FTP client, an IDE, deployment tool, backup job, cron task, or custom script.

If the same connections simply remain in closing states and gradually disappear without new ones appearing, inspect timeout behavior and session shutdown instead. Do not increase MaxClients until you know why connections are not being released.

How to find another source of FTP connections

On Windows, check background processes and applications with saved FTP settings. On Linux, inspect processes and network connections. If the FTP user is used by automated deployment, backups, or scripts, temporarily stop those tasks and compare the session count again.

The confirmation is straightforward: stop one specific process and the new FTP connections stop appearing. If sessions continue to return, the source has not been found yet.

How to tell whether other devices or users behind the same IP are hitting the limit

Only one FileZilla session may be open on your laptop while the server shows several connections from your IP. The remaining sessions may belong to other devices behind the same NAT gateway.

PC --------\
Laptop ----- Router / NAT ----- Public IP ----- FTP server
NAS --------/

The FTP server sees the public address of the gateway. If a per-IP limit applies to that address, connections from several local devices may be added together even when each computer only has one or two sessions.

Home and office networks

Consider an office with three developers. Each uses a separate FTP user and several parallel transfers, but all of them access the internet through one public IP. If the per-IP limit is lower than their total session count, the third user may receive 421 even though their own FileZilla configuration is perfectly normal.

Test it like this:

1. Record the public IP of the problematic connection.
2. Check whether other devices on the network are using FTP.
3. Temporarily stop their transfers.
4. Perform one clean FTP connection.
5. If possible, repeat the test through another network with a different public IP.

If the same FTP user connects successfully from another public IP, that is strong evidence for a per-IP restriction or accumulated sessions from the original address. Do not change MaxClientsPerUser yet.

One FTP user on several computers

The opposite scenario is also possible. Two computers are on different networks and have different public IPs, but both use the same FTP login. In that case, a per-user limit may be reached instead. The text of 421 alone often cannot distinguish these scenarios, which is why an IP × FTP user test is useful.

VPN, corporate gateways, and CGNAT

A similar situation may occur with a VPN or corporate gateway: several clients can reach the FTP server through one shared address. Some ISP networks can create a comparable effect with CGNAT. NAT itself does not prove the cause of 421, but the shared public IP must be considered whenever a per-IP restriction is involved.

If the user switches a VPN on and off during troubleshooting, the source IP may change between tests. Record the address for every attempt; otherwise, results such as “it works now” and “it fails now” are not directly comparable.

Where to check and change FTP server connection limits

If FileZilla is already limited to one transfer, unnecessary clients are closed, the IP has been checked, and 421 is still consistently reproducible, inspect the FTP daemon itself. Pure-FTPd settings should not be blindly applied to ProFTPD, or vice versa.

How to find the active configuration instead of editing the first file you see

On a server with a control panel or non-standard installation, the active configuration may not be stored at the path shown in the first online tutorial you find. The daemon may use a main configuration file, include files, a directory of individual parameters, or configuration generated by a hosting panel.

Start by identifying the daemon and its startup arguments:

ps -eo pid,args | grep -E '[p]roftpd|[p]ure-ftpd'

Then search the configuration of that specific service. If the same restriction appears in several files, do not immediately edit the first one. Determine which file is actually part of the active configuration and whether a panel will overwrite it.

How to check Pure-FTPd limits

Pure-FTPd configurations may include settings such as MaxClientsNumber and MaxClientsPerIP. On one system they may be stored in the main configuration file, while another may use individual parameter files inside a Pure-FTPd configuration directory.

You can search for them with:

grep -RniE 'MaxClients(Number|PerIP)' /etc/pure-ftpd* 2>/dev/null

If the output shows separate settings for total clients and clients per IP, compare them with the actual connection count. Finding a line does not prove that it caused 421: the configuration may be generated by a wrapper or hosting panel.

If grep finds nothing, that does not automatically mean there is no limit. The FTP daemon may use defaults or receive options at startup.

How to check ProFTPD limits

ProFTPD can apply restrictions at several levels:

• MaxClients — total client limit;
• MaxClientsPerHost — limit for one source host or IP;
• MaxClientsPerUser — limit for one FTP user.

Search the configuration for these directives:

grep -RniE '^[[:space:]]*MaxClients(PerHost|PerUser)?' /etc/proftpd /etc/proftpd.conf 2>/dev/null

Paths differ between distributions, so a missing directory or file in this command does not by itself indicate a configuration problem.

A typical ProFTPD fragment may look like this:

MaxClientsPerHost 5 "Too many connections from your host"

If the server is actually applying this rule and already counts five sessions from one IP, the sixth connection will be rejected as expected. At that point, the configuration value and the number of sessions at the moment of 421 support the same diagnosis.

How to validate the configuration after a change

Before reloading or restarting the service, check the configuration syntax with the daemon's own tools when supported. For ProFTPD, a commonly used test is:

proftpd -t

The command should complete without a syntax error. If the server uses a non-standard configuration path or is managed by a control panel, the required options may differ.

After changing the limit, do not stop at “FTP login works again.” Compare:

• how many sessions existed before the change;
• which limit was active;
• how many connections appear during normal use afterward;
• whether sessions are released when transfers finish.

If FTP is managed by a hosting control panel

cPanel, ISPmanager, and other panels may generate service configuration automatically. A manual change to a generated file may survive only until the next configuration rebuild, after which the panel restores its own value.

If the hosting account does not provide root access, the server-side limit may be unavailable to the user entirely. You can still collect useful evidence: the client connection count, public IP, exact time of the 421 response, and whether the problem is reproducible. Send that information to support together with the exact FTP error.

Where to find confirmation of FTP 421 in server logs

The server log is not useful merely because it repeats the message shown by FileZilla. Its value is in linking the rejection to a specific IP, user, time, and FTP daemon state. This becomes especially useful when several users receive 421 or when connections continue to reappear after the client has been closed.

How to view the systemd journal

If the FTP daemon runs as a systemd service, start with recent messages:

journalctl -u proftpd --since "-10 min"
journalctl -u pure-ftpd --since "-10 min"

The unit name may differ. Check the service that is actually running on the server.

The exact message format depends on the daemon and its configuration. The log may contain connection, login, disconnect, and limit-related events. A simplified diagnostic sequence could look like this:

connection from 198.51.100.25
login for user example
connection from 198.51.100.25
too many connections from 198.51.100.25

This is not a universal ProFTPD or Pure-FTPd log format. It demonstrates the relationship to look for: the same IP creates several sessions and the daemon then rejects another connection.

What if FTP writes to a separate log file?

ProFTPD and Pure-FTPd may use dedicated log files, syslog, or journald. Paths depend on the distribution, hosting panel, and daemon configuration, so no single /var/log/... path should be treated as universal for every VPS.

Check the daemon logging configuration and the system log directory first. If you know when the error occurred, search around that exact time instead of reading a large log file from the beginning.

Which log indicators are actually useful?

• the source IP matches the problematic client;
• several connections from the same IP appear before 421;
• the same FTP user logs in from several IPs;
• different users receive rejections at the same time;
• new connections appear after FileZilla is closed;
• the error timestamp matches the moment a configured limit is reached.

The log, TCP connections, and configuration should tell the same story. If MaxClientsPerHost is 5, the server sees five active sessions from one IP, and the sixth attempt receives 421 at that moment, the cause is much better established than by the FileZilla error text alone.

How to distinguish an IP limit, FTP user limit, and global server limit

The 421 message does not always reveal which internal limit was reached. A better approach is to change one variable at a time: first the IP, then the FTP user, while comparing the result with active server-side sessions.

An IP × FTP user matrix works well for this.

Scenario 1: the same user works from another IP

Do not stop at “the IP must be the problem.” Check the number of sessions from the original address and compare it with the per-IP limit. If IP A holds five sessions with a limit of 5 while IP B has one and works, the hypothesis now has server-side confirmation.

Scenario 2: one FTP user fails from every network

If User A gets 421 both from the office and mobile internet while User B connects normally to the same server, inspect per-user limits and sessions for User A. One FTP login may be used simultaneously on several computers, in an IDE, and by a deployment script.

Scenario 3: different users from different IPs receive 421

This no longer looks like a local FileZilla problem. Check the FTP daemon's global client limit. If different users begin receiving 421 at roughly the same time and the server has reached MaxClients, increasing a per-IP limit will not help.

Do not change the IP, FTP user, and configuration at the same time. If the connection starts working afterward, you will not know which change fixed it.

1. Record the source IP, FTP user, and current number of active sessions.
2. Repeat the test with the same user from another IP.
3. Check server-side connections again.
4. Repeat the test with another user from the original IP.
5. If necessary, perform a fourth test with another user from another IP.
6. Compare the result with per-IP, per-user, and global limits.

Change one variable at a time. Otherwise, troubleshooting turns into guesswork.

Why simply increasing the connection limit can be a bad idea

An administrator changes MaxClientsPerHost from 5 to 50 and the 421 error disappears. Some time later, the same faulty script may occupy all 50 connections. In that case, the limit was not the root cause — it was a safety barrier.

A connection limit prevents one IP, one FTP user, or one faulty process from consuming client slots without control. Raise it only when the current value is demonstrably below normal workload requirements.

How to choose a new limit when the current value is genuinely too low

There is no universal recommendation such as “set it to 20.” A private VPS with one user and an office where several developers work behind one NAT gateway have very different requirements.

Start with the actual workload instead of choosing a random number:

1. Count the users or devices that normally work at the same time.
2. Observe how many parallel FTP sessions each client creates during normal use.
3. Account separately for automated deployment and backup jobs.
4. Add a reasonable margin for short periods of overlap.
5. Do not set an extremely high value simply to make the restriction disappear.
6. After changing it, monitor real sessions instead of checking only whether 421 is gone.

A simplified test might look like this:

Before:
4/4 sessions
new session -> 421

After changing the limit:
4/8 sessions
new session -> connection allowed

This confirms that the new value removed that specific restriction. It does not prove that 8 is the correct permanent limit. You still need to observe normal server behavior and verify that the client does not simply fill the new ceiling.

Mistakes that still occur when troubleshooting FTP 421

• Changing the FTP password. 421 is about connection limits, not invalid authentication.
• Setting a very large limit. This can hide a reconnect loop.
• Restarting the entire VPS. When the problem is FTP-specific, work with the FTP daemon first.
• Editing a file generated by the control panel. The setting may disappear after the configuration is rebuilt.

FTP, FTPS, and SFTP are not the same thing

FTP and FTPS are handled by an FTP server: FTPS adds TLS to the FTP protocol, so FTP daemon settings remain relevant. SFTP runs over SSH and does not use Pure-FTPd or ProFTPD as a regular FTP daemon. If the problem occurs over SFTP, FTP parameters such as MaxClientsPerHost do not directly explain it.

Before changing a limit, describe the situation in one sentence: which FTP user is connecting, from which IP, how many sessions are already open, and which daemon is serving them. Without those facts, it is too early to change the configuration.

How to verify that FTP 421 is really fixed

One successful login after closing FileZilla or restarting the FTP daemon proves very little. Restore the normal workload and check whether the number of sessions starts climbing toward the limit again.

1. Create one FTP connection.
2. Transfer one file.
3. Check the number of active sessions.
4. Add a small queue.
5. Restore the normal number of parallel transfers.
6. Disconnect and connect again.
7. If other people use the server, test a second FTP user.
8. Make sure sessions are released after transfers finish.

The fix can be considered stable when the number of FTP sessions rises during real transfers and then drops again, new connections do not receive 421, and reconnect behavior does not create an endless chain of sessions.

If 421 returns, compare three things at the same moment: the FTP client log, server-side connections, and the active FTP daemon limit. They should explain one another.

For example, if the server sees five active connections from one IP, MaxClientsPerHost is 5, and the sixth attempt receives 421, the scenario is confirmed. If new connections continue appearing while FileZilla is closed, do not change the limit yet — first find the process that is creating them.

This type of control test distinguishes a real fix from a temporary effect after a service restart.