Varnish Nginx 503 Error Server

Error 503 backend.max_conn
Reached

Your backend server hit its maximum connection limit and is refusing new requests. Here's what it means and exactly how to fix it — whether you're running Varnish, Nginx, or another proxy.

Fast Fix Summary

Ordered from fastest relief to long-term resolution.

# Action Component Impact
1Increase max_connections in Varnish backend configVarnish VCLImmediate relief
2Increase Nginx worker_processes and worker_connectionsNginxImmediate relief
3Enable Varnish's grace period to serve stale cacheVarnish VCLReduces 503 visibility
4Add database connection pooling (PgBouncer etc.)DB LayerRoot cause fix
5Scale horizontally — add backend server nodesInfrastructureLong-term

What Does "503 backend.max_conn reached" Mean?

This error originates from Varnish Cache. When Varnish routes a request to a backend (your web server, app server, or API), it checks if the backend has capacity. Each Varnish backend has a max_connections parameter. When all connection slots are occupied, Varnish rejects the incoming request with a 503 Service Unavailable and the message "backend.max_conn reached."

Nginx, HAProxy, and other reverse proxies have analogous limits under different names. The root cause is almost always either too many concurrent users, slow backend responses causing connections to pile up, or the limit being set too low for actual traffic volume.

Configuration Fixes

1

Increase Varnish Backend max_connections

Edit your Varnish VCL file and increase the max_connections value on your backend definition:

# /etc/varnish/default.vcl
backend default {
.host = "127.0.0.1";
.port = "8080";
.max_connections = 300; /* was 75 */
.connect_timeout = 5s;
.first_byte_timeout = 60s;
}

Reload with: service varnish reload

2

Enable Grace Mode in Varnish

Grace mode lets Varnish serve stale cached content while the backend is overloaded, preventing users from seeing 503 errors:

# In your VCL vcl_backend_response
set beresp.grace = 1h;
# In vcl_hit
if (obj.ttl + obj.grace > 0s) {'{'}
return(deliver);
{'}'}
3

Tune Nginx Worker Connections

In /etc/nginx/nginx.conf:

worker_processes auto;
events {'{'}
worker_connections 4096;
use epoll;
multi_accept on;
{'}'}
http {'{'}
keepalive_timeout 65;
keepalive_requests 100;
{'}'}

Test and reload: nginx -t && systemctl reload nginx

4

Identify Slow Queries / Long-Running Processes

Connection slots often pile up because backend requests are slow. Check for slow database queries, unoptimised PHP processes, or third-party API calls holding connections open.

# Check active connections on Linux
ss -s
netstat -an | grep ESTABLISHED | wc -l

FAQ

What's the right value for max_connections in Varnish?

It depends on your backend's capacity. A safe starting point is max_connections = (worker_threads × 0.8). Monitor with varnishstat and adjust based on real traffic.

Is this error always caused by traffic spikes?

Not always. Memory leaks, database deadlocks, or third-party API timeouts can cause backend threads to hang, consuming connection slots even under normal traffic.

Can a CDN prevent this error?

A CDN reduces origin traffic by serving cached assets at the edge, which can significantly reduce backend connection pressure during traffic spikes.

More server error fixes at LogCure.