Wenn OpenClaw auf einem gemeinsamen Remote-Mac läuft und dieselbe Maschine oder derselbe Benutzer go mod download für CI oder Hooks ausführt, reicht ein statisches GOPROXY in ~/.zshrc nicht: launchd-Jobs und ephemere Runner sehen die Datei oft nicht, und bei intermittierendem Egress versagt der erste Proxyhop ohne erklärbares Log. Dieser Text liefert eine minimale, kopierbare Kette: Baseline mit openclaw onboard und openclaw doctor, ein Bash-Wrapper mit Health-Probes und Retry-Schwellen, optionaler LaunchAgent-Patrol sowie ein Muster, wie Sie CI-Logs so anreichern, dass der fehlgeschlagene Hop ohne SSH erkennbar ist. Vertiefung zu Variablen und Matrizen: Go-Module GOPROXY-Matrix; Betriebsnahe Gateway-Überwachung: Gateway-Healthcheck & LaunchAgent.

① Ausgangslage: go mod download scheitert trotz „richtiger“ Umgebung

Typische Symptome sind Timeouts gegen den ersten Eintrag in GOPROXY, TLS-Handshakes hinter Unternehmens-HTTP-Proxies oder 410/Checksum-Konflikte nach Proxy-Wechseln. Auf einem Multi-Tenant-Mac verschärft das Problem, wenn Team A den Mirror wechselt und Team B denselben GOMODCACHE sieht. Bevor Sie Ketten blind rotieren, sollten Sie den Automatisierungs-Host wie einen Produktionsserver behandeln: dieselbe Node-Baseline wie für OpenClaw, konsistente Proxy-Variablen für curl und go, und nachvollziehbare Artefakte pro Job.

Für Installations- und Doctor-Fallstricke (Berechtigungen, Pfade, häufige Fehlermeldungen) siehe OpenClaw Installation & Troubleshooting.

② Checkliste: Installation, Doctor, Daemon-Pfade

  • Node 22+ für das OpenClaw-CLI; which node und which openclaw im gleichen Kontext prüfen wie der CI-Agent (nicht nur in der interaktiven Shell).
  • openclaw onboard ausführen und dokumentierte Defaults übernehmen; anschließend openclaw doctor bis keine kritischen Warnungen zu Gateway-Pfaden oder fehlenden Abhängigkeiten mehr erscheinen.
  • HTTPS ohne Prompt: Test-curl -I https://proxy.golang.org mit denselben HTTPS_PROXY/NO_PROXY-Werten wie im Job; Zertifikats-Overrides nur über NODE_EXTRA_CA_CERTS oder System-Trust, nicht dauerhaft -k.
  • Go-Toolchain pinnten (go version in CI und auf dem Host identisch); GOMODCACHE und GOTMPDIR pro Job-ID trennen, um Locking zwischen parallelen Pipelines zu vermeiden.
  • Secrets: private Module über GOPRIVATE/GONOPROXY alignen; niemals Tokens in tee-Dateien oder CI-Summary im Klartext.

③ Skript-Vorlage: GOPROXY-Health-Probe mit Retry-Schwellen

Die Probe soll bounded sein: keine endlosen Schleifen auf einem geteilten Mac. Empfehlung: drei Versuche pro URL, connect-timeout 8, max-time 20, Backoff 2s → 4s → 8s. Für öffentliche Module-Proxies reicht oft ein HEAD/GET auf einen bekannten Modulpfad; HTTP 200 oder 404 auf einer Versions-URL werten wir als „Endpoint antwortet“. Schlägt ein Kandidat dreimal fehl, wird der nächste in der komma-separierten Liste gewählt.

#!/usr/bin/env bash set -euo pipefail CANDIDATES=( "https://ihr-interner-athens.example" "https://goproxy.cn,direct" "https://proxy.golang.org,direct" ) # Lebend-Check: erster Hop der Kette (HEAD); bei internem Athens ggf. PROBE_PATH anpassen probe_base() { local base="$1" attempt=1 while [[ "$attempt" -le 3 ]]; do if curl -fsS --connect-timeout 8 --max-time 20 -o /dev/null -I "$base" \ --proxy "${HTTPS_PROXY:-}" 2>/dev/null; then return 0 fi [[ "$attempt" -eq 3 ]] && return 1 case "$attempt" in 1) sleep 2;; 2) sleep 4;; esac attempt=$((attempt + 1)) done return 1 } for chain in "${CANDIDATES[@]}"; do first="${chain%%,*}" if probe_base "$first"; then export GOPROXY="$chain" echo "GOPROXY aktiv: $GOPROXY" >&2 exit 0 fi done echo "Alle GOPROXY-Kandidaten fehlgeschlagen" >&2 exit 1

Dieses Muster in einen frühen CI-Schritt oder ein ~/bin/go-mod-prelude.sh legen, das vor go mod download source-t wird. Für strengere Prüfungen können Sie statt -I "$base" einen festen Modul-List-Pfad unter dem jeweiligen Proxy testen.

④ go mod download wrappen: Rotation und Abbruchkriterien

Nach erfolgreicher Probe: einmalig go mod download. Scheitert der Lauf, go env -json GOPROXY GOPRIVATE GOSUMDB GOMODCACHE und die letzten 50 Zeilen von stderr sichern, dann eine zweite dokumentierte Kette setzen (z. B. mit ausdrücklichem direct am Ende, sofern Firewall-Policies das erlauben). Als Obergrenze empfehlen wir zwei vollständige Kettenrotationen pro Job – mehr verschleiert oft strukturelle Netzprobleme und belastet Upstreams.

LOG="${CI_ARTIFACT_DIR:-/tmp}/go-mod-fetch.log" set +e go mod download -x 2>&1 | tee "$LOG" rc=${PIPESTATUS[0]} set -e if [[ "$rc" -ne 0 ]]; then echo "go mod download fehlgeschlagen (rc=$rc), siehe $LOG" >&2 go env -json GOPROXY GOPRIVATE GOSUMDB 2>&1 | tee -a "$LOG" || true exit "$rc" fi

⑤ CI-Log-Rückkopplung: Zusammenfassung für den Orchestrator

Die wertvollste Zeile für Entwickler ist oft: welcher Proxyhop war aktiv, und welcher ist zuerst gestorben? Schreiben Sie nach der Probe eine einezeilige Zusammenfassung in eine vom CI-System eingelesene Datei (z. B. $GITHUB_STEP_SUMMARY oder ein Team-internes Äquivalent): GOPROXY=…, Exit-Code, Pfad zum vollständigen Log. So entfällt SSH auf den Remote-Mac für die erste Triage.

Beispiel GitHub Actions (nach erfolgreicher Probe): echo "**GOPROXY** \`$GOPROXY\` (Health: OK)" >> "$GITHUB_STEP_SUMMARY". Bei Fehlschlag von go mod download zusätzlich die letzte Zeile der Fehlermeldung anhängen – aber URLs mit eingebetteten Tokens vorher maskieren. Andere Orchestratoren bieten ähnliche Summary-Dateien oder Artefakt-Uploads; wichtig ist nur, dass dieselbe Information im Job-UI ohne Zugang zur Konsole sichtbar wird.

⑥ Optional: LaunchAgent-Patrol für den gleichen Host

Wenn OpenClaw und Go-Builds denselben Egress teilen, kann ein LaunchAgent die Probe alle 15–30 Minuten ausführen. Setzen Sie ThrottleInterval in der plist, loggen Sie nach ~/Library/Logs/goproxy-probe.log, und lösen Sie Benachrichtigungen erst nach zwei aufeinanderfolgenden Fehlschlägen mit mindestens fünf Minuten Abstand – wie im oben verlinkten Gateway-Healthcheck-Leitfaden beschrieben, damit kurze Netz-Ripples keinen Alarm-Sturm erzeugen.

⑦ Manuell Umgebungsvariablen vs. automatisierte Proxy-Auswahl

Aspekt Manuell (.zshrc / export im Terminal) Skript + Probe vor go mod download
Reproduzierbarkeit Abhängig von Login-Shell und interaktiven Defaults Gleicher Codepfad für CI, SSH und LaunchAgent
Sichtbarkeit Fehler oft nur lokal sichtbar tee + Summary-Zeile für das Team
Fallback Erfordert manuelles Umschalten bei Ausfällen Automatische Kandidatenliste mit Retry-Schwellen
Wartung Schnell für Einzelpersonen Einmalig mehr Aufwand, dafür Operations-tauglich

⑧ Kurz-FAQ

Reicht es, GOPROXY nur in der Konsole zu setzen?
Für lokale Tests ja; für CI und launchd meist nein – nutzen Sie den Wrapper oder ein explizites env-Block in der Pipeline.
Wie verhält sich das zu Athens oder internen Proxies?
Ersetzen Sie CANDIDATES und PROBE_URL durch Ihre internen Endpunkte; die Retry-Logik bleibt gleich.
Muss OpenClaw selbst Go-Module ziehen?
Nicht zwingend; doctor/onboard sichern aber ab, dass der Host nicht wegen kaputter Node-/Pfad-Basics alle Folgeschritte verfälscht.

Fazit

Fazit: Kapseln Sie GOPROXY mit Health-Probes, begrenzten Retries und einem klaren Abbruch nach zwei Kettenrotationen; verankern Sie die Baseline mit openclaw onboard/doctor und spiegeln Sie Ergebnisse in CI-Artefakten. So werden go mod download-Fehler auf Remote-Macs operabel statt mysteriös.

Nächste Schritte

Knoten- und Dokumentationsseiten ohne Anmeldezwang.

Startseite Jetzt kaufen Hilfe Technik-Blog