Türkei (Türkisch)
Germany (German)
Worldwide (English)
AnforderungsflussClient, NGINX und Backend-Verbindungsbrempunkt
Halkali Merkez Viertel Fatih Str. Ozgur Apt. No. 46, Kucukcekmece, Istanbul, 34303, TR
Wenn NGINX bei hohem Traffic neue Verbindungen nicht akzeptieren kann und Sie "worker_connections are not enough" oder "too many open files" sehen, sollte nur eine Zahl erhöht werden. Die Anzahl der Worker, die Datei-Descriptor-Grenze, Proxy-Verbindungen, Keepalive, WebSocket und Bot-Verkehr sollten gemeinsam gemessen werden.
2026/07/17 04:27:03 [alert] 2511#2511: 1024 worker_connections are not enough
2026/07/17 04:27:04 [crit] 2511#2511: accept4() failed (24: Too many open files)Der gleichzeitige Verbindungslimit für jeden NGINX-Worker wird durch worker_connections bestimmt. Reverse-Proxy-Verbindungen, Upstream-Sockets und einige offene Dateien verbrauchen auch Deskriptoren; die theoretische Kapazität kann den Betriebssystemlimit nicht überschreiten.
worker_processes sollte auf auto auf den meisten Systemen gesetzt werden, da es auf der CPU-Basis Arbeiter erstellt; obwohl es scheinen mag, als wäre die Gesamtkapazität der Clienten einfach worker_processes × worker_connections, in Proxy-Verwendung ist jedoch für jeden Client eine zusätzliche Upstream-Verbindung erforderlich.
worker_rlimit_nofile kann die offene Dateilimits der NGINX-Arbeiter erhöhen, aber es sollte mit systemd LimitNOFILE und den Prozess-Soft- und -Hartelimits konsistent sein.
Langzeit-Keepalive, WebSocket- oder SSE-Verbindungen können auch bei niedrigem Anforderungstraffik viele Verbindungen offen halten. stub_status, ss und /proc-Prozesslimits sollten gemeinsam überwacht werden.
Erhöhen Sie den Limit nicht allein, ohne zu untersuchen, ob der plötzliche Limitwarnung durch einen Bot/DDoS, langsamen Client, upstream-Verbindungsleak oder falsche Keepalive-Konfiguration verursacht wurde.
Wenn ein Proxy-Client im Kapazitätskonto verwendet wird, sollten sowohl Client- als auch Upstream-Verbindungen berücksichtigt werden; der tatsächliche Wert sollte mit stub_status und process fd Zahl gemessen werden.
Suchen Sie nach dem Ausdruck, den Sie in der E-Mail, im Browser oder im SSH-Protokoll sehen. Jede Karte enthält eine Bedeutung, eine wahrscheinliche Ursache und eine sichere erste Maßnahme.
Bedeutung: Ein Worker hat die definierte Grenze für neue Verbindungen erreicht.
Mögliche Ursache: Niedrige Grenze, lange Links oder Verkehrsschwemme
Bedeutung: Der Prozess kann keinen neuen Socket/Datei-Descriptor öffnen.
Mögliche Ursache: Der NOFILE-soft/hard- oder systemd-Limit ist zu niedrig.
Bedeutung: Es konnte kein Upstream- oder Client-Socket erstellt werden.
Mögliche Ursache: Descriptor-Grenze oder -Leck.
Bedeutung: Ein Socket blieb während des Reloads offen.
Mögliche Ursache: Langsame Verbindung oder Modulverhalten.
Bedeutung: Der lokale Ephemeral-Port oder Netzwerkressource könnte erschöpft sein.
Mögliche Ursache: Zu viele upstream-Verbindungen oder TIME_WAIT.
Bedeutung: Der Verbindungslimit ist nicht direkt gefüllt, aber die Worker/Backend-Warteschlange wächst.
Mögliche Ursache: Upstream-Kapazität ist niedriger als bei NGINX.
Bedeutung: Die gängige Standard-/Beispielswert kann für ein starkes System möglicherweise nicht ausreichen.
Mögliche Ursache: Keine Kapazitätsplanung für die Konfiguration.
Bedeutung: Die Anwendung oder der NGINX-Prozess hat die Grenze für Dateideskriptoren erreicht.
Mögliche Ursache: Limit oder Datei/Socket-Leak.
Es wurden keine Datensätze gefunden, die diesem Ausdruck entsprechen.
Befehle sind für den Root-Zugriff vorgesehen. Sammeln Sie zunächst nur den Status und die Protokolle. Ändern Sie die dauerhafte Einstellung nicht, ohne den Grund dafür zu erkennen.
nginx -T | grep -nE 'worker_processes|worker_connections|worker_rlimit_nofile|keepalive_timeout|keepalive_requests'Zeigt aktive Kapazitäts- und Verbindungslaufzeit-Einstellungen an.
MASTER=$(cat /run/nginx.pid); cat /proc/$MASTER/limits | grep -i 'open files'
for p in $(pgrep -f 'nginx: worker'); do echo PID=$p FD=$(ls /proc/$p/fd | wc -l); cat /proc/$p/limits | grep -i 'open files'; doneMaster und Worker zeigen die tatsächlichen NOFILE-Grenzwerte/fd-Nutzung an.
ss -s
ss -ant state established | wc -l
ss -ant state time-wait | wc -lMisst aktive, etablierte und TIME_WAIT-Verbindungen.
curl -s http://127.0.0.1/nginx_statusZeigt die Werte Active, akzeptiert, bearbeitet, Anfragen, Lesen/Schreiben/Warten an.
systemctl show nginx -p LimitNOFILE
systemctl cat nginxZeigt die offene Dateilimit in den Serviceeinheit- und Überschreibungsdateien an.
nginx -t && systemctl reload nginx
systemctl show nginx -p LimitNOFILEWenden Sie die Konfigurationsänderung an und überprüfen Sie die Dienstgrenze.
Obwohl die Grundursache des NGINX-Fehlers dieselbe ist, variieren Paketpfade, Dienstnamen, Sicherheitsebenen und die Verwaltung virtueller Hosts je nach verwendeter Linux-Distribution oder Plesk-Infrastruktur.
NGINX Worker Connections und Open Files für systemd, Paketpfad und journald-Prüfunglen.
nginx -T | grep -nE 'worker_processes|worker_connections|worker_rlimit_nofile'
systemctl show nginx -p LimitNOFILE
ss -sNGINX Worker Connections und Open Files für SELinux, PHP-FPM-Pool und RHEL-basierte Dienstekontrollen.
nginx -T | grep -nE 'worker_processes|worker_connections|worker_rlimit_nofile'
systemctl show nginx -p LimitNOFILE
ss -sNGINX virtuelle Hostdateien, die von Plesk generiert werden: Prüfungle von nginx-Arbeitsscharen und offenen Dateien.
nginx -T | grep -nE 'worker_processes|worker_connections|worker_rlimit_nofile'
systemctl show nginx -p LimitNOFILE
plesk repair web -nZuerst messen Sie die tatsächliche Verbindung/FD-Nutzung und die Verkehrstypen; dann passen Sie die NGINX-, systemd- und Betriebssystemgrenzwerte an, um sie kompatibel zu machen.
Bestimmen Sie, ob es sich um Bot-Traffic, normales Wachstum oder WebSocket/Keepalive handelt
date; uptime; ss -sWorker-Zähler, Verbindungsbeschränkung und rlimit-Werte speichern.
nginx -T | grep -nE 'worker_processes|worker_connections|worker_rlimit_nofile'Vergleichen Sie den Konfigurationswert mit /proc-Grenzwerten und offener Deskriptoranzahl.
for p in $(pgrep -f 'nginx: worker'); do echo -n "$p "; ls /proc/$p/fd | wc -l; doneTrennen Sie etablierte, wartende, TIME_WAIT-, WebSocket- und Upstream-Verbindungen.
ss -ant | awk 'NR>1 {s[$1]++} END {for(k in s) print k,s[k]}'worker_connections, worker_rlimit_nofile und systemd LimitNOFILE sollten zusammen geplant werden.
systemctl show nginx -p LimitNOFILENach dem Reload, die fd-Zahl, stub_status und error_log-Warnungen verfolgen.
nginx -t && systemctl reload nginx
watch -n2 'ss -s; curl -s http://127.0.0.1/nginx_status'Wenn die Obergrenze erhöht wurde, ist eine IP-/URI-Verteilung und ein Rate-Limiting-Plan erforderlich.
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | headLanglaufende Verbindungen verbrauchen Arbeitskapazität.
ss -antp | grep nginx | wc -lWarten Verbindungen und der keepalive_timeout-Wert werden untersucht.
curl -s http://127.0.0.1/nginx_status; nginx -T | grep keepalive_timeoutFür jeden Client zusätzliche Upstream-Sockets berücksichtigen.
ss -antp | grep nginx | headWenn die Anzahl der Dateideskriptoren eines Workers ständig ansteigt, werden offene Ziele untersucht.
lsof -p $(pgrep -f 'nginx: worker' | head -1) | head -n 50Globaler nginx.conf, Web-Server-Vorlage und Domain-Traffic werden gemeinsam bewertet.
nginx -T | grep worker_connections; ss -sLegt die Obergrenze für die Anzahl der Verbindungen fest, die jeder Worker-Prozess gleichzeitig öffnen kann; Proxy-Verbindungen von oben sind auch in dieser Zahl enthalten
Worker-Processes und worker-Connections werden ungefährlich berüksichtigt, aber der Datei-Descriptor-Limit, Proxy-Connections und der Verkehrstyp verringern die tatsächliche Kapazität.
Process NOFILE, systemd LimitNOFILE, worker_rlimit_nofile und der tatsächliche fd-Verwendung müssen miteinander kompatibel sein.
Nein. Es wird unwirksam sein, wenn die Betriebssystemgrenze niedrig ist; es kann das Problem verschlimmern, wenn es Bot-Traffic oder fd-Lecks gibt.
Aktive Verbindungen, Akzeptierungen, Verarbeitungen, Anfragen, die die Anzahl der lesenden/schreibenden/wartenden Verbindungen anzeigen.
Ja. Jeder lange geöffnete WebSocket-Client und meistens verbraucht die Upstream-Verbindung.
systemctl show nginx -p LimitNOFILE und überprüfen Sie gemeinsam die /proc/PID/limits-Datei des laufenden Arbeiters.
Durch die gemeinsame Analyse von cPanel, WHM, CloudLinux, LiteSpeed, MariaDB, Exim und Sicherheitsebenen beheben wir die Grundursache des Fehlers, anstatt nur den Dienst zu entfernen.