Hey there, let's break this down clearly for you to untangle what's happening here:

首先，明确这个101错误的核心本质 #

The connect() failed (101: Network is unreachable) while resolving error is primarily a network or DNS resolution issue, not a direct result of upstream (PHP-FPM) capacity limits. The while resolving part is key here—it means NGINX was trying to resolve a domain name (either for your upstream PHP-FPM server if you configured it with a domain, or for external links you were pushing in chat) and couldn't reach the DNS server or complete the resolution due to network unreachability.

为什么它和PHP-FPM进程满载同时出现（且活动期间频率上升）？ #

While the 101 error isn't caused by PHP-FPM being maxed out, high traffic from your live event could have triggered both issues simultaneously, or indirectly exposed the network/DNS problem:

• DNS request overload: During the event, the surge in traffic might have flooded your server with DNS resolution requests (either for upstream services or external chat links). If your local DNS cache was too small, or your configured DNS server couldn't handle the spike, you'd see more of these unreachable errors.
• EC2 network resource limits: Your EC2 instance might have hit its outbound bandwidth or TCP connection limits during the event. This would block DNS requests from being sent/received, leading to the 101 error, while also straining PHP-FPM as it tried to handle all the incoming traffic.
• Indirect overlap: PHP-FPM maxing out would cause 502 errors on its own, but those would show up in NGINX logs as connection refused or no live upstreams—not the 101 network unreachable error. The two issues are separate but were amplified by the same high-load scenario.

你的核心问题：Can this 101 error relate to upstream capacity? #

Short answer: No, not directly. The 101 error is strictly tied to network/DNS resolution failures. However, high upstream load (PHP-FPM maxing out) can coincide with this error if the same traffic spike that overwhelmed PHP-FPM also pushed your network/DNS resources to their limits.

下一步排查和修复建议 #

• Switch upstream to IP or Unix socket: If your NGINX config uses a domain name to point to PHP-FPM, replace it with 127.0.0.1 (or a Unix socket like unix:/run/php-fpm.sock)—this bypasses DNS resolution entirely and eliminates this source of errors, while also improving performance.
• Tune NGINX DNS resolver settings: If you need to keep using domains, add a resolver directive with a reasonable cache time (e.g., resolver 8.8.8.8 valid=300s;) to reduce repeated DNS queries.
• Check EC2 network metrics: Use AWS CloudWatch to look at outbound bandwidth, TCP connections, and network latency during the event—this will tell you if your instance hit network limits.
• Address PHP-FPM capacity: Even though it's not the cause of the 101 error, maxed-out child processes are a critical bottleneck. Adjust pm.max_children, pm.start_servers, and pm.min_spare_servers in your PHP-FPM config based on your instance's CPU/memory, or consider upgrading your EC2 tier if needed.

备注：内容来源于stack exchange，提问作者rguttersohn