Absturzschleife des Proxy Managers: IP-Bereich-Abruf abschaltbar

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>

scripts/cmk-manage.sh

@@ -3309,6 +3309,7 @@ npm|NPM_ADMIN_EMAIL|text|Konto des Proxy Managers (E-Mail)||1
 npm|NPM_ADMIN_PASSWORD|password|Kennwort des Proxy-Manager-Kontos||1
 npm|NPM_ADMIN_PORT|port|Port der Adminoberflaeche||
 npm|NPM_API_HOST|text|Name fuer die Schnittstelle (127.0.0.1 oder localhost)||1
+npm|NPM_IP_RANGES_FETCH|choice|IP-Bereiche von AWS/Cloudflare holen|false:true|1
 npm|PROXY_DOMAIN|text|Vorgabe-Domain fuer Proxy-Hosts||1
 npm|PROXY_FORWARD_HOST|text|Weiterleitungsziel (Host)||
 npm|PROXY_FORWARD_PORT|port|Weiterleitungsziel (Port)||
@@ -3445,7 +3446,7 @@ settings_post_set() {
             cmd_cert_external --watch "$val" ;;
         CERT_EXTERNAL_DIR)
             log "Wirksam nach:  $SELF up   (das Verzeichnis wird erst dann eingehaengt)" ;;
-        CMK_IMAGE|CMK_SITE_ID|CMK_CONTAINER_NAME|NPM_IMAGE|NPM_CONTAINER_NAME|TZ|CMK_LIVESTATUS_TCP|NPM_DISABLE_IPV6|CMK_DATA_DIR|NPM_DATA_DIR|NPM_LE_DIR)
+        CMK_IMAGE|CMK_SITE_ID|CMK_CONTAINER_NAME|NPM_IMAGE|NPM_CONTAINER_NAME|TZ|CMK_LIVESTATUS_TCP|NPM_DISABLE_IPV6|CMK_DATA_DIR|NPM_DATA_DIR|NPM_LE_DIR|NPM_IP_RANGES_FETCH)
             log "Wirksam nach:  $SELF up   (Container werden neu erstellt)" ;;
     esac
 }
@@ -3771,6 +3772,37 @@ json_str() { printf '%s' "$1" | tr ',' '\n' | sed -n "s/.*\"$2\"[[:space:]]*:[[:
 # certificate_id oder owner_user_id zu, weil dort ein _ vor dem id steht.
 json_ids() { printf '%s' "$1" | grep -o '"id":[0-9]*' | sed 's/.*://' ; }
 
+# Stirbt der Dienst hinter nginx in einer Schleife? Das sieht von aussen
+# aus wie "startet noch", hoert aber nie auf. Im Protokoll steht es.
+npm_diagnose_backend() {
+    container_running "$NPM_CONTAINER_NAME" || return 0
+    local log starts crash
+    log="$($RUNTIME logs --tail 200 "$NPM_CONTAINER_NAME" 2>&1 || true)"
+    starts="$(printf '%s\n' "$log" | grep -c 'Starting backend' || true)"
+    crash="$(printf '%s\n' "$log" | grep -c 'Uncaught Error' || true)"
+    [ "${starts:-0}" -ge 3 ] || [ "${crash:-0}" -ge 2 ] || return 0
+
+    printf '
+      %sDer Dienst startet nicht nur - er stuerzt in einer Schleife ab.%s
+      Im Protokoll: %s Startversuche, %s unbehandelte Ausnahmen.\n' \
+           "$C_YEL" "$C_RST" "${starts:-0}" "${crash:-0}" >&2
+
+    case "$log" in
+        *ip-ranges.amazonaws.com*|*"IP Ranges"*)
+            printf '
+      Die Ausnahmen kommen vom Abruf der IP-Bereiche bei AWS und
+      Cloudflare. In Netzen, die TLS aufbrechen oder Verbindungen kappen,
+      faellt der Dienst darueber - und startet endlos neu. Abschalten:
+        %s config set NPM_IP_RANGES_FETCH false
+        %s up
+      Gebraucht wird der Abruf nur fuer Zugriffslisten mit den
+      Adressbereichen von AWS oder Cloudflare.\n' "$SELF" "$SELF" >&2 ;;
+        *)
+            printf '      Letzte Ausnahme im Protokoll:
+        %s\n' "$(printf '%s\n' "$log" | grep -A1 'Uncaught Error' | tail -1 | cut -c1-70)" >&2 ;;
+    esac
+}
+
 npm_api_token() {
     local base; base="$(npm_api_base)"
     if [ -z "${NPM_ADMIN_EMAIL:-}" ] || [ -z "${NPM_ADMIN_PASSWORD:-}" ]; then
@@ -3911,11 +3943,12 @@ EOF
                         printf '      Der Proxy Manager selbst hat geantwortet (%s) - aber der
       Dienst DAHINTER ist nicht erreichbar. Das ist normal, solange er
       noch startet: nach einem Neustart dauert es rund zehn Sekunden,
-      bis die Schnittstelle antwortet.
-
-      Kurz warten und noch einmal, sonst ins Protokoll sehen:
+      bis die Schnittstelle antwortet.\n' "$srv" >&2
+                        npm_diagnose_backend
+                        printf '
+      Sonst ins Protokoll sehen:
         %s logs
-        %s proxy restart\n' "$srv" "$SELF" "$SELF" >&2
+        %s proxy restart\n' "$SELF" "$SELF" >&2
                     else
                         printf '      Die Antwort kam ueber einen Proxy (Via: %s), nicht direkt.
       Pruefen:  %s noproxy\n' "$via" "$SELF" >&2