FileZilla Server Max Connections vs. Client Transfer Concurrency: Which Setting Best Mitigates Intermittent 421 Errors?

Short answer

Raise the server's maximum simultaneous connections — that is the authoritative fix for 421 "Too many connections" during legitimate bursts. Client-side transfer concurrency is a useful complement, but it cannot prevent 421 errors on its own, because it only governs how many transfers one cooperative client opens and does nothing about the aggregate connection count from all clients.

Why the server limit is the enforcement point

The 421 response is generated by the server when either the global connection limit or the per-IP limit is exceeded. Every session consumes at least one control connection, and each active transfer adds a data connection. The FileZilla Client's "maximum simultaneous transfers" setting (in Settings → Transfers) caps how many data connections a single queued session opens at once — it does not limit how many clients connect, and a busy queue of many small files can still hold a control connection open for a long time.

This means:

• In a multi-user environment, you cannot centrally enforce client settings. One client with 10 concurrent transfers is indistinguishable from ten clients with one each, as far as the server's counter is concerned.
• Lowering client concurrency only reduces the rate at which new connections appear. If total demand exceeds the server cap, 421s still occur — just slightly later.

What should guide the decision

Treat this as a capacity question: set the server limit as high as your measured headroom allows, then use per-IP limits and client concurrency as shaping tools.

1. Observed connection counts: Watch the FileZilla Server administration interface during peak load. If "current connections" regularly hits the configured maximum while 421s appear in the log, the limit is the bottleneck.
2. File descriptors: Each connection consumes a socket. On Linux, confirm the process limit with cat /proc/<pid>/limits and ensure LimitNOFILE (or ulimit -n) comfortably exceeds your planned max connections plus headroom for data sockets and log files.
3. Memory and CPU: Resource use scales roughly linearly with active sessions. Measure baseline usage, then load-test with a realistic client mix and observe per-connection cost before committing to a new ceiling.
4. Ephemeral ports / NAT: If many clients sit behind one NAT address, the per-IP limit — not the global limit — may be what actually triggers 421. Check which limit the log implicates before changing anything.

Practical configuration

In the FileZilla Server admin interface, raise Maximum number of connections to a value your load test showed is safe, and set a per-IP limit that reflects your heaviest legitimate single source (NAT'd offices often need a higher per-IP allowance). Then, where you control the clients, cap simultaneous transfers at 2–3 to smooth bursts and reduce queue churn for many small files.

Verification

Reproduce the failure first: run several clients concurrently until 421s appear, note the connection count at failure, raise the limit, and confirm the same load now completes without 421s while CPU, memory, and descriptor usage stay within budget. If 421s persist despite headroom in the global count, the per-IP limit or an OS-level socket restriction is the next suspect — that distinction is the one diagnostic detail that changes the recommendation.