PHP-FPM "connect() failed (111: Connection refused) while connecting to upstream"

The error string in nginx error.log:

*1234 connect() failed (111: Connection refused) while connecting to upstream, client: 10.0.0.5, server: example.com, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/run/php/php8.2-fpm.sock:"

errno 111 is ECONNREFUSED. nginx tried to open a connection to the FastCGI backend and the kernel on the PHP-FPM side rejected it before any FastCGI bytes were exchanged. Users see HTTP 502 Bad Gateway in batches.

Four failure modes present identically from nginx’s seat: the PHP-FPM master is not running; the configured socket path or TCP address does not match what nginx is dialing; the kernel dropped the connection because the listen backlog is full; or the socket exists and paths match, but something environmental prevents nginx from reaching it (private tmp namespace, container network boundary, IPv6/IPv4 mismatch, socket permissions). One read-only check on the FPM host disambiguates all four: is anything actually listening on the address nginx is trying to reach?

This page covers the link-layer refusal. If nginx can connect but the request never finishes in time, see the related 504 guide.

What this means

connect() is the syscall nginx issues against the address in fastcgi_pass. ECONNREFUSED is returned synchronously by the kernel when:

• the destination address has no listener bound to it (no process called listen() on it), or
• the listener’s accept queue (the backlog) is full and the kernel’s policy for that socket is to refuse rather than silently drop.

For a Unix socket, an absent socket file usually produces ENOENT (“no such file or directory”) rather than ECONNREFUSED, but nginx reports both under the same connect() failed prefix. A refused Unix socket typically means the file exists but no process is accepting on it (master died, stale socket left behind) or the path resolves into a different mount namespace from nginx’s perspective. For TCP, ECONNREFUSED with the port closed and ECONNREFUSED with the backlog full look identical to nginx.

The diagnostic that matters: separate a dead listener from a saturated one. A dead listener has zero capacity and refuses every connection. A saturated listener is technically up, the ping endpoint may still answer, and only connections that arrive faster than workers can accept() are refused. Mixing these two leads to the wrong fix (raising pm.max_children on a pool that never started).

flowchart TD
    A["nginx error.log
connect() failed (111)"] --> B{"Master running?
pgrep php-fpm"}
    B -- No --> C["FPM down or crashed
journalctl, dmesg"]
    B -- Yes --> D{"Socket listening?
ss -lnp"}
    D -- No --> E["listen path/address wrong
or bind failed"]
    D -- Yes --> F{"nginx fastcgi_pass
matches listen?"}
    F -- No --> G["Config drift between
nginx and pool"}
    F -- Yes --> H{"Backlog full?
Recv-Q at limit"}
    H -- Yes --> I["Worker saturation
refused at kernel"]
    H -- No --> J["Environmental block:
PrivateTmp, container net,
IPv6, perms, SELinux"]

Common causes

Quick checks

# Is the master alive? expect one master plus N workers
pgrep -af php-fpm

# What is FPM actually listening on? (-p needs root for the pid column)
ss -lnp | grep -E 'php|9000'

# What does nginx dial? confirm the fastcgi_pass target
nginx -T 2>/dev/null | grep -i fastcgi_pass

# What does the pool config say it listens on? (-tt parses and dumps effective config, no daemon)
php-fpm -tt 2>&1 | grep -E 'listen\s*=|listen\.backlog'

# Does the socket file exist with the expected owner/mode?
ls -l /run/php /var/run/php* 2>/dev/null

# Is the backlog currently full? Recv-Q on the LISTEN line vs the configured backlog
ss -tlnp | grep -E '9000|php'
ss -xlnp | grep php

# Kernel-side refusals since boot (cumulative counters)
nstat -z 2>/dev/null | grep -iE 'ListenOverflows|ListenDrops'

# FPM's own view of saturation
curl -s http://127.0.0.1/fpm-status | grep -E 'listen queue|active processes|max children'

# Recent FPM errors and any reload window
journalctl -u php-fpm --since "30 min ago" --no-pager | tail -50

All of these are read-only.

How to diagnose it

1. Confirm whether the master is running. pgrep -af php-fpm should show one master process line plus worker lines. If it shows nothing, the refusal is a dead listener, not saturation. Go to the master-down path below.

2. Confirm something is listening on the address nginx dials. Copy the fastcgi_pass value out of nginx -T and check ss -lnp for that exact path or ip:port. For a Unix socket, the path must match character for character. For TCP, the bound address family matters: a listener on 127.0.0.1:9000 will not satisfy fastcgi_pass [::1]:9000.

3. Cross-check paths between nginx and the pool. Run php-fpm -tt and read the listen = line for the www pool (or whichever pool nginx targets). The two values must agree. A common drift source is a distro upgrade that moves sockets from /var/run/php5-fpm.sock to /run/php/php8.2-fpm.sock while the nginx vhost is never updated.

4. If the listener is up and paths match, check the backlog. Look at ss -tlnp (TCP) or ss -xlnp (Unix). The Recv-Q column on the LISTEN line is the current depth of the accept queue. If Recv-Q sits at the configured listen.backlog (or net.core.somaxconn, whichever is smaller) and refuses to drain, the kernel is refusing new connections. Cross-check with nstat -z | grep -iE 'ListenOverflows|ListenDrops': a rising counter confirms kernel-level refusals. This is a saturation problem, not a connectivity problem.

5. If none of the above apply, look for an environmental block. ls -l the socket file and confirm the nginx worker user has read/write access. On systemd hosts, check whether php-fpm.service runs with PrivateTmp=true (systemctl show php-fpm -p PrivateTmp): a socket under /tmp or /var/tmp is invisible to nginx in a different tmp namespace. In containers, confirm the FPM container is listening on 0.0.0.0:9000 or its bridge IP, not 127.0.0.1:9000, which is unreachable from the nginx container’s loopback. On SELinux hosts, ausearch -m AVC -ts recent will surface denials on the socket path.

The single question that splits the investigation cleanly: does the FPM status page respond while nginx is logging 502s? If yes, the pool is alive and you are looking at saturation or an environmental block. If no, the master is down or the socket is unreachable.

Metrics and signals to monitor

Fixes

Master not running

Find out why before restarting. The refusal is the symptom; the master died or never started for a reason. Pull journalctl -u php-fpm -n 100 for the startup error. Common causes: a pool config syntax error after a deploy, a missing PHP extension pulled in by new code, the error log directory not being writable, or an OOM kill of the master visible in dmesg. Validate the config before bringing the service back:

# Config-test only; exits non-zero on syntax errors with details
php-fpm -tt

Restarting as the first action hides the root cause and gives you the same outage again on the next deploy.

Wrong socket path or address

Align the two configs. Set listen = in the pool to a stable path under /run/php/ (or /var/run/php/, which is the same directory on modern distros) and point fastcgi_pass at exactly that path. For TCP, ensure both sides agree on address family and port. For Unix sockets, also set the ownership and mode so the nginx worker user can read and write:

listen = /run/php/php8.2-fpm.sock
listen.owner = www-data
listen.group = www-data
listen.mode = 0660

The listen.owner and listen.group directives must match the user nginx workers run as. Wrong ownership produces EACCES (“permission denied”) in nginx, which reports under the same connect() failed prefix but with a different errno (13).

Backlog overflow (saturation)

This is not a connection problem; it is a capacity problem that surfaces as a connection problem. Do not raise listen.backlog as the fix. A deeper queue just delays the refusal by seconds and hides the real signal. The actual fixes are: raise pm.max_children if memory headroom exists, or remove the slow dependency that is holding workers hostage. The saturation pattern, the slow-log-driven root cause, and the memory math for raising max_children are covered in the related guides below.

One configuration note: listen.backlog defaults changed across PHP versions. PHP 8.2 and later default to -1 on Linux, which the kernel clamps to net.core.somaxconn (commonly 4096 on modern kernels). PHP before 8.2 defaults to 511. If you rely on the default, the effective backlog depends on both the PHP version and the kernel sysctl.

Environmental blocks

• systemd PrivateTmp: if php-fpm.service has PrivateTmp=true and the pool listens on a socket under /tmp or /var/tmp, nginx cannot see that socket. Move the socket under /run/php/ (preferred) or override with a drop-in setting PrivateTmp=false.
• Container networking: a PHP-FPM container listening on 127.0.0.1:9000 is unreachable from the nginx container’s loopback. The FPM pool must listen on 0.0.0.0:9000 or the container’s bridge IP, and nginx must fastcgi_pass to the FPM container’s service name or IP, not 127.0.0.1.
• IPv6 resolution of localhost: fastcgi_pass localhost:9000 can resolve to ::1 on IPv6-enabled hosts while FPM listens only on 127.0.0.1. Use explicit addresses: 127.0.0.1:9000.
• SELinux: AVC denials can block nginx from connecting to the FPM socket. Check ausearch -m AVC -ts recent and the audit log.

Prevention

• Run php-fpm -tt and nginx -t in CI on every config change. Most path mismatches are deploy-time drift that a syntax check would have caught.
• Health-check the actual socket nginx dials, not just the systemd unit. A cgi-fcgi or curl probe against the real fastcgi_pass target catches dead listeners and stale sockets that systemctl is-active misses.
• Alert on listen queue depth and kernel ListenOverflows before they become 502s. By the time nginx logs connect() failed, the backlog is already full and users are already seeing errors.
• Keep the FPM listen directive and the nginx fastcgi_pass in the same config source (templated from one variable) so they cannot drift independently.
• Standardize socket placement under /run/php/ to sidestep PrivateTmp and /tmp-namespace issues entirely.

How Netdata helps

• Per-second collection of the PHP-FPM status page (listen queue, active processes, idle processes, max children reached) catches saturation in the window before the backlog overflows, where 10-second polling misses the buildup entirely.
• The nginx collector surfaces upstream 5xx rates per server block, so the 502 burst is visible against normal traffic at the same resolution as the FPM pool metrics.
• Kernel socket counters (TcpExtListenOverflows, TcpExtListenDrops) and the ss view of the FPM listen socket correlate directly with the nginx error log, confirming whether a 502 burst is a dead listener or a saturated one.
• Process and systemd collectors flag the master going away within a second, separating a crash from a saturation event without manual pgrep. For containerized FPM, cgroup memory metrics and OOM-kill events explain a missing master that systemctl would never see.

Related guides

• PHP-FPM 504 Gateway Timeout: requests accepted but never finishing in time
• PHP-FPM active processes near max_children: reading pool utilization
• PHP-FPM in containers: cgroup limits and the silent OOM kill
• PHP-FPM listen queue growing: the earliest signal of saturation
• PHP-FPM “server reached pm.max_children setting (N), consider raising it”
• PHP-FPM crash loop and fork storm: workers dying faster than they serve
• PHP-FPM graceful reload: the brief no-worker window on SIGUSR2