Das Containerprotokoll eines Kunden zeigte, was hinter dem 502 steckte:
der Dienst stuerzt in einer Schleife ab.
[IP Ranges] Fetching https://ip-ranges.amazonaws.com/ip-ranges.json
Uncaught Error: Client network socket disconnected before secure TLS
connection was established
... node --abort_on_uncaught_exception ... index.js
Starting backend ... [und das immer wieder]
Beim Start holt der Proxy Manager IP-Bereiche von AWS und Cloudflare -
gebraucht wird das nur fuer Zugriffslisten mit deren Adressbereichen,
auf einem internen Server also nie. Der Code faengt Fehler dabei ab,
dieser kommt aber asynchron vom TLS-Socket und laeuft am catch vorbei;
weil node mit --abort_on_uncaught_exception laeuft, bricht der Prozess
ab, s6 startet neu, und nginx davor antwortet durchgehend mit 502.
Am Abbild nachgesehen und ausprobiert:
- IP_RANGES_FETCH_ENABLED=false verhindert den Abruf; im Protokoll
steht dann "IP Ranges fetch is disabled by environment variable",
das Backend laeuft.
- Scheitert der Abruf sauber (DNS-Fehler, Verbindung abgelehnt), faengt
der Code ihn ab und der Dienst laeuft weiter - der Absturz haengt
also wirklich an der gekappten TLS-Verbindung.
- initTimer() laeuft unabhaengig vom Schalter und versucht es alle
sechs Stunden erneut. Das steht als Hinweis samt extra_hosts in der
README.
Neu: NPM_IP_RANGES_FETCH, Vorgabe false. Und die Fehlermeldung erkennt
den Fall selbst - sie zaehlt Startversuche und Ausnahmen im
Containerprotokoll und nennt den Schalter, statt den Benutzer weiter auf
"startet noch" warten zu lassen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
duffyduckandClaude Opus 5
58308264c6