Proxy-Einstellungen für curl und wget: Praktische Beispiele für Systemadministratoren und DevOps

Wenn Sie Server administrieren, Automatisierungsskripte schreiben oder Anwendungen in einer Unternehmensinfrastruktur bereitstellen — werden Sie früher oder später mit der Notwendigkeit konfrontiert, den Traffic von curl oder wget über einen Proxy zu leiten. Dies kann ein Unternehmensproxy sein, um Geo-Blockaden beim Herunterladen von Paketen zu umgehen, oder um IPs bei massenhaften Anfragen an externe APIs zu rotieren. In diesem Artikel — nur die Praxis: Befehle, Konfigurationen, Codebeispiele ohne Schnickschnack.

1. Wie curl und wget mit Proxys arbeiten: Grundmechanismen

Bevor Sie in die Konfigurationen eintauchen, ist es wichtig zu verstehen, was unter der Haube passiert. Beide Werkzeuge unterstützen zwei Hauptprotokolle für Proxys: HTTP/HTTPS und SOCKS5. Die Mechanik ist unterschiedlich, und das beeinflusst, welchen Proxytyp Sie für eine bestimmte Aufgabe wählen sollten.

HTTP-Proxy fungiert als Vermittler auf der Ebene des Anwendungsprotokolls. Wenn curl eine Anfrage über einen HTTP-Proxy sendet, sagt es dem Proxy-Server buchstäblich: „Mach einen GET-Request auf diese URL anstelle von mir“. Für HTTPS-Traffic wird die CONNECT-Methode verwendet — curl bittet den Proxy, einen Tunnel zum Zielhost einzurichten, wonach das TLS-Handshake direkt zwischen dem Client und dem Zielserver erfolgt. Das ist wichtig: Der Proxy sieht in diesem Fall den Inhalt des HTTPS-Traffics nicht.

SOCKS5 arbeitet auf einer niedrigeren Ebene — es proxyiert TCP/UDP-Verbindungen ohne Bindung an ein Anwendungsprotokoll. Das macht SOCKS5 universeller: Über ihn können nicht nur HTTP/HTTPS, sondern auch andere Protokolle geleitet werden. Darüber hinaus unterstützt SOCKS5 die DNS-Auflösung auf der Seite des Proxy-Servers — das ist entscheidend, um DNS-Lecks zu verhindern.

curl unterstützt beide Protokolle nativ seit sehr frühen Versionen. wget hatte historisch gesehen eine eingeschränktere Unterstützung für SOCKS5 — in älteren Versionen (vor 1.19) gibt es überhaupt keine Unterstützung für SOCKS5, nur für HTTP-Proxys. Das sollte bei der Erstellung von Skripten berücksichtigt werden, die auf verschiedenen Distributionen funktionieren sollen.

Die Version von wget kann mit dem Befehl wget --version überprüft werden. Für curl — curl --version, dort wird auch angezeigt, mit welchen Protokollen die libcurl-Bibliothek kompiliert wurde.

2. Umgebungsvariablen: der schnellste Weg zur Einrichtung

Der eleganteste Weg, um Proxys für curl und wget einzurichten, ist über Umgebungsvariablen. Das funktioniert systemweit: Es ist nicht notwendig, jedes Skript zu ändern, es reicht aus, die Variablen einmal in der Sitzung festzulegen oder sie im Benutzerprofil hinzuzufügen.

Beide Werkzeuge lesen die gleichen Standardvariablen:

# Für HTTP-Traffic
export http_proxy="http://proxy.example.com:3128"

# Für HTTPS-Traffic
export https_proxy="http://proxy.example.com:3128"

# Duplizieren in Großbuchstaben (einige Programme lesen nur diese)
export HTTP_PROXY="http://proxy.example.com:3128"
export HTTPS_PROXY="http://proxy.example.com:3128"

# Für FTP (falls benötigt)
export ftp_proxy="http://proxy.example.com:3128"

# Ausnahmen — Adressen, die NICHT über den Proxy gehen
export no_proxy="localhost,127.0.0.1,::1,192.168.0.0/16,.internal.company.com"

Ein wichtiger Punkt: curl ist je nach Version empfindlich gegenüber der Groß- und Kleinschreibung der Variablen. Um Überraschungen zu vermeiden — setzen Sie immer beide Versionen: in Klein- und Großbuchstaben. Das ist eine gängige Praxis in DevOps.

Damit die Einstellungen dauerhaft für einen bestimmten Benutzer gelten, fügen Sie die Zeilen in ~/.bashrc oder ~/.profile hinzu. Für Systemskripte und Dienste — in /etc/environment oder in die Unit-Datei von systemd über die Direktive Environment=.

# /etc/systemd/system/myservice.service
[Service]
Environment="http_proxy=http://proxy.example.com:3128"
Environment="https_proxy=http://proxy.example.com:3128"
Environment="no_proxy=localhost,127.0.0.1"
ExecStart=/usr/bin/myapp

Wenn der Proxy eine Authentifizierung erfordert, werden Benutzername und Passwort direkt in die URL der Variablen eingefügt:

export http_proxy="http://username:[email protected]:3128"
export https_proxy="http://username:[email protected]:3128"

3. curl-Flags zur Arbeit mit Proxys: vollständige Analyse

curl bietet eine Vielzahl von Flags zur Steuerung des Proxys direkt aus der Kommandozeile. Das ist praktisch, wenn Sie eine einmalige Anfrage über einen Proxy machen möchten, ohne die Systemeinstellungen zu ändern.

Das Hauptflag ist -x oder --proxy:

# Basis-HTTP-Proxy
curl -x http://proxy.example.com:3128 https://api.example.com/data

# Kurze Form
curl -x proxy.example.com:3128 https://api.example.com/data

# Mit expliziter Angabe des Protokolls
curl --proxy http://proxy.example.com:3128 https://api.example.com/data

# Überprüfen Sie die externe IP über den Proxy
curl -x http://proxy.example.com:3128 https://api.ipify.org

Um Umgebungsvariablen zu ignorieren und eine direkte Verbindung herzustellen (Proxy umgehen), wird das Flag --noproxy verwendet:

# Proxy für einen bestimmten Host ignorieren
curl --noproxy "internal.company.com" https://internal.company.com/api

# Proxy vollständig ignorieren (auch wenn env-Variablen gesetzt sind)
curl --noproxy "*" https://api.example.com/data

Nützliche Flags zur Fehlersuche bei Proxy-Verbindungen:

# Verbose-Modus: alle Header sichtbar, einschließlich CONNECT zum Proxy
curl -v -x http://proxy.example.com:3128 https://api.example.com/data

# Nur die Header der Antwort
curl -I -x http://proxy.example.com:3128 https://api.example.com/data

# Zeigen Sie die Verbindungszeit über den Proxy an
curl -w "Connect: %{time_connect}s\nTotal: %{time_total}s\n" \
  -x http://proxy.example.com:3128 \
  -o /dev/null -s https://api.example.com/data

Die Proxy-Einrichtung über die Konfigurationsdatei ~/.curlrc ist praktisch, wenn Sie nicht jedes Mal die Flags angeben möchten:

# ~/.curlrc
proxy = http://proxy.example.com:3128
proxy-user = username:password
noproxy = localhost,127.0.0.1,.internal.company.com

Für Systemskripte kann eine separate Konfiguration erstellt und explizit über curl -K /path/to/config angegeben werden — dies ermöglicht es, verschiedene Proxy-Profile für unterschiedliche Aufgaben zu haben.

4. Proxy in wget einrichten: Flags und Konfigurationsdatei

wget ist weniger flexibel als curl, aber für typische Aufgaben — das Herunterladen von Dateien, rekursives Spiegeln von Websites — sind seine Möglichkeiten völlig ausreichend. Proxys in wget können auf drei Arten eingerichtet werden: über Umgebungsvariablen (wie oben behandelt), über Kommandozeilenflags und über die Konfigurationsdatei ~/.wgetrc.

Kommandozeilenflags von wget für Proxys:

# HTTP-Proxy über Flag
wget -e use_proxy=yes \
     -e http_proxy=http://proxy.example.com:3128 \
     https://example.com/file.tar.gz

# HTTPS über Proxy
wget -e use_proxy=yes \
     -e https_proxy=http://proxy.example.com:3128 \
     https://example.com/file.tar.gz

# Mit Authentifizierung
wget -e use_proxy=yes \
     -e http_proxy=http://username:[email protected]:3128 \
     https://example.com/file.tar.gz

# Proxy für einen bestimmten Befehl deaktivieren (wenn env-Variablen gesetzt sind)
wget --no-proxy https://internal.company.com/file.tar.gz

Die Konfigurationsdatei ~/.wgetrc ist der bevorzugte Weg für eine dauerhafte Einrichtung:

# ~/.wgetrc
use_proxy = on
http_proxy = http://proxy.example.com:3128
https_proxy = http://proxy.example.com:3128
ftp_proxy = http://proxy.example.com:3128
no_proxy = localhost,127.0.0.1,.internal.company.com

# Wenn der Proxy Authentifizierung erfordert
proxy_user = username
proxy_password = secretpassword

Für die systemweite Anwendung (alle Benutzer) wird /etc/wgetrc verwendet — dasselbe Format, aber global angewendet. Praktisch für Server, bei denen alle Download-Operationen über den Unternehmensproxy laufen müssen.

Praktisches Beispiel: rekursives Herunterladen einer Website über einen Proxy mit Tiefen- und Geschwindigkeitsbegrenzung:

wget -e use_proxy=yes \
     -e http_proxy=http://proxy.example.com:3128 \
     --recursive \
     --level=2 \
     --limit-rate=500k \
     --wait=1 \
     --random-wait \
     --user-agent="Mozilla/5.0 (compatible; Googlebot/2.1)" \
     https://example.com/docs/

5. SOCKS5-Proxy in curl und wget: Einrichtung und Beispiele

SOCKS5 ist das bevorzugte Protokoll für Aufgaben, bei denen Anonymität oder die Arbeit mit nicht standardmäßigen Ports wichtig ist. Für Systemadministratoren und DevOps-Ingenieure wird SOCKS5 häufig bei der Arbeit über SSH-Tunnel sowie bei der Verbindung zu residential Proxys verwendet, die den Traffic realer Benutzer imitieren.

In curl wird SOCKS5 über einen speziellen Präfix in der Proxy-URL unterstützt:

# SOCKS5 mit DNS-Auflösung auf der Client-Seite (kann zu DNS-Lecks führen!)
curl --socks5 proxy.example.com:1080 https://api.example.com/data

# SOCKS5 mit DNS-Auflösung auf der Proxy-Seite (empfohlen!)
curl --socks5-hostname proxy.example.com:1080 https://api.example.com/data

# Über das Flag -x mit expliziter Angabe des Protokolls
curl -x socks5h://proxy.example.com:1080 https://api.example.com/data

# Mit Authentifizierung
curl -x socks5h://username:[email protected]:1080 https://api.example.com/data

# SOCKS5 über Umgebungsvariable
export all_proxy="socks5h://proxy.example.com:1080"
curl https://api.example.com/data

Ein beliebtes Szenario in DevOps ist die Verwendung von SSH als SOCKS5-Proxy, um den Traffic über einen Bastion-Host zu tunneln:

# SSH-Tunnel mit SOCKS5 auf dem lokalen Port 1080 öffnen
ssh -D 1080 -f -C -q -N [email protected]

# Jetzt verwenden wir diesen Tunnel in curl
curl -x socks5h://localhost:1080 https://internal-api.private.network/data

# Oder über die Umgebungsvariable für alle Anfragen in der Sitzung
export all_proxy="socks5h://localhost:1080"
wget https://internal-resource.private.network/file.tar.gz

wget unterstützt SOCKS5 seit Version 1.19. In älteren Versionen (CentOS 7, Ubuntu 16.04) müssen Umgehungslösungen verwendet werden: proxychains, tsocks oder auf curl umsteigen für Aufgaben, die SOCKS5 erfordern.

6. Authentifizierung am Proxy: Benutzername und Passwort

Die meisten kommerziellen Proxys und Unternehmensproxy-Server erfordern eine Authentifizierung. Es gibt mehrere Möglichkeiten, die Anmeldeinformationen zu übermitteln — jede mit ihren eigenen Vor- und Nachteilen in Bezug auf Sicherheit.

Methode 1: Anmeldeinformationen in der URL — einfach, aber unsicher (Passwort ist in der Prozessliste sichtbar):

curl -x http://user:p%[email protected]:3128 https://api.example.com/data
# Sonderzeichen im Passwort müssen URL-kodiert werden: @ → %40, : → %3A

Methode 2: Flag --proxy-user in curl — das Passwort muss nicht in der Kommandozeile angegeben werden, curl fragt es interaktiv ab:

# Benutzername und Passwort im Flag (immer noch in ps aux sichtbar)
curl -x http://proxy.example.com:3128 \
     --proxy-user "username:password" \
     https://api.example.com/data

# Nur Benutzername — curl fragt das Passwort interaktiv ab
curl -x http://proxy.example.com:3128 \
     --proxy-user "username" \
     https://api.example.com/data

Methode 3: Über die .netrc-Datei — die sicherste Methode für Skripte:

# ~/.netrc
machine proxy.example.com
login username
password secretpassword

# Berechtigungen für die Datei einschränken
chmod 600 ~/.netrc

# In curl verwenden
curl -x http://proxy.example.com:3128 --proxy-netrc https://api.example.com/data

Methode 4: Über Umgebungsvariablen aus einem Secret Vault — empfohlen für CI/CD und Produktionsumgebungen:

# Im Skript lesen wir die Anmeldeinformationen aus den Variablen (die von CI/CD gesetzt werden)
#!/bin/bash
PROXY_URL="http://${PROXY_USER}:${PROXY_PASS}@proxy.example.com:3128"
curl -x "${PROXY_URL}" https://api.example.com/data

Vergleichstabelle der Authentifizierungsmethoden:

7. Ausnahmen und no_proxy: wie man Proxys für lokale Adressen umgeht

In Unternehmens- und Cloud-Umgebungen ist oft eine feine Abstimmung erforderlich: externer Traffic — über den Proxy, interner — direkt. Die Variable no_proxy (oder NO_PROXY) ermöglicht es, eine Liste von Ausnahmen festzulegen.

# Basis-Ausnahmen
export no_proxy="localhost,127.0.0.1,::1"

# Ausnahme nach Domain (mit Punkt — alle Subdomains)
export no_proxy="localhost,127.0.0.1,.internal.company.com,.corp.local"

# Ausnahme nach IP-Bereich (CIDR-Notation funktioniert nicht überall!)
export no_proxy="localhost,127.0.0.1,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16"

# Für AWS: metadata endpoint und interne Adressen ausschließen
export no_proxy="localhost,127.0.0.1,169.254.169.254,.amazonaws.com.internal"

Praktisches Beispiel für eine Kubernetes-Umgebung, in der der API-Server und interne Dienste ausgeschlossen werden müssen:

export no_proxy="localhost,127.0.0.1,10.96.0.0/12,10.244.0.0/16,.cluster.local,.svc,.default"
export NO_PROXY="${no_proxy}"

8. Proxy in CI/CD: GitHub Actions, GitLab CI, Docker

Die Einrichtung von Proxys in CI/CD-Pipelines ist eine der häufigsten Aufgaben für DevOps-Ingenieure, die in Unternehmensnetzwerken oder mit eingeschränktem Internetzugang arbeiten. Lassen Sie uns spezifische Konfigurationen für beliebte Plattformen durchgehen.

GitHub Actions

# .github/workflows/deploy.yml
name: Deploy

on: [push]

jobs:
  deploy:
    runs-on: ubuntu-latest
    env:
      http_proxy: ${{ secrets.PROXY_URL }}
      https_proxy: ${{ secrets.PROXY_URL }}
      no_proxy: "localhost,127.0.0.1,.github.com"
    
    steps:
      - uses: actions/checkout@v3
      
      - name: Abhängigkeiten herunterladen
        run: |
          curl -x "${http_proxy}" https://external-api.example.com/config.json -o config.json
          wget -e use_proxy=yes -e http_proxy="${http_proxy}" https://releases.example.com/app-v1.0.tar.gz

GitLab CI

# .gitlab-ci.yml
variables:
  http_proxy: "http://proxy.company.com:3128"
  https_proxy: "http://proxy.company.com:3128"
  no_proxy: "localhost,127.0.0.1,.gitlab.company.com"

build:
  stage: build
  script:
    - curl -x "${http_proxy}" https://registry.npmjs.org/package -o package.json
    - wget -e use_proxy=yes -e http_proxy="${http_proxy}" https://example.com/resource.tar.gz

Docker: Proxy bei der Erstellung von Images

# Proxy über Build-Argumente übergeben
docker build \
  --build-arg http_proxy=http://proxy.example.com:3128 \
  --build-arg https_proxy=http://proxy.example.com:3128 \
  --build-arg no_proxy=localhost,127.0.0.1 \
  -t myapp:latest .

# Im Dockerfile verwenden wir ARG, um die Variablen zu erhalten

# Dockerfile
FROM ubuntu:22.04

ARG http_proxy
ARG https_proxy
ARG no_proxy

ENV http_proxy=${http_proxy}
ENV https_proxy=${https_proxy}
ENV no_proxy=${no_proxy}

RUN apt-get update && apt-get install -y curl wget

RUN curl -x "${http_proxy}" https://example.com/setup.sh | bash

# Proxy-Variablen im finalen Image bereinigen (optional)
ENV http_proxy=""
ENV https_proxy=""

Globale Proxy-Einstellungen für den Docker-Daemon (für docker pull über Proxy):

# /etc/systemd/system/docker.service.d/proxy.conf
[Service]
Environment="HTTP_PROXY=http://proxy.example.com:3128"
Environment="HTTPS_PROXY=http://proxy.example.com:3128"
Environment="NO_PROXY=localhost,127.0.0.1,.internal.registry.com"

# Docker neu starten
systemctl daemon-reload
systemctl restart docker

9. Proxy-Rotation in Bash-Skripten

Wenn Sie eine große Anzahl von Anfragen an externe APIs oder Dienste stellen müssen — ermöglicht die Proxy-Rotation, die Last zu verteilen und IP-Sperren zu vermeiden. Dies ist besonders relevant beim Preis-Monitoring, beim Datensammeln oder beim Testen der Verfügbarkeit von Ressourcen aus verschiedenen Regionen.

Für solche Aufgaben eignen sich Datacenter-Proxys gut — sie bieten hohe Geschwindigkeit und Stabilität bei massenhaften Anfragen.

#!/bin/bash
# rotate_proxy.sh — Proxy-Rotation aus einer Liste

PROXY_LIST=(
  "http://user:[email protected]:3128"
  "http://user:[email protected]:3128"
  "http://user:[email protected]:3128"
  "http://user:[email protected]:3128"
)

URLS_FILE="urls.txt"
OUTPUT_DIR="./results"
mkdir -p "${OUTPUT_DIR}"

PROXY_COUNT=${#PROXY_LIST[@]}
INDEX=0

while IFS= read -r url; do
  PROXY="${PROXY_LIST[$INDEX]}"
  FILENAME=$(echo "${url}" | md5sum | cut -d' ' -f1)
  
  echo "Anfrage: ${url} über Proxy $((INDEX + 1))/${PROXY_COUNT}"
  
  curl -x "${PROXY}" \
       --max-time 30 \
       --retry 3 \
       --retry-delay 2 \
       --silent \
       --output "${OUTPUT_DIR}/${FILENAME}.html" \
       "${url}"
  
  if [ $? -eq 0 ]; then
    echo "  ✓ Erfolg"
  else
    echo "  ✗ Fehlgeschlagen, versuche nächsten Proxy..."
    INDEX=$(( (INDEX + 1) % PROXY_COUNT ))
    curl -x "${PROXY_LIST[$INDEX]}" \
         --max-time 30 \
         --silent \
         --output "${OUTPUT_DIR}/${FILENAME}.html" \
         "${url}"
  fi
  
  # Zum nächsten Proxy wechseln
  INDEX=$(( (INDEX + 1) % PROXY_COUNT ))
  
  # Kleine Pause zwischen den Anfragen
  sleep 0.5
  
done < "${URLS_FILE}"

echo "Fertig! Ergebnisse gespeichert in ${OUTPUT_DIR}"

Eine fortgeschrittenere Variante — die Überprüfung der Funktionsfähigkeit des Proxys vor der Verwendung:

#!/bin/bash
# check_proxy.sh — Überprüfung der Erreichbarkeit des Proxys

check_proxy() {
  local proxy_url="$1"
  local test_url="https://api.ipify.org"
  
  result=$(curl -x "${proxy_url}" \
                --max-time 10 \
                --silent \
                --write-out "%{http_code}" \
                --output /dev/null \
                "${test_url}")
  
  if [ "${result}" -eq 200 ]; then
    echo "ALIVE"
  else
    echo "DEAD"
  fi
}

# Externe IP über den Proxy abrufen
get_proxy_ip() {
  local proxy_url="$1"
  curl -x "${proxy_url}" --max-time 10 --silent https://api.ipify.org
}

PROXY="http://user:[email protected]:3128"
STATUS=$(check_proxy "${PROXY}")
echo "Proxy-Status: ${STATUS}"

if [ "${STATUS}" == "ALIVE" ]; then
  EXTERNAL_IP=$(get_proxy_ip "${PROXY}")
  echo "Externe IP über den Proxy: ${EXTERNAL_IP}"
fi

10. Fehlerbehebung und typische Fehler

Die Arbeit mit Proxys geht unvermeidlich mit Fehlern einher — insbesondere bei der Erstkonfiguration. Lassen Sie uns die häufigsten Probleme und deren Diagnosetechniken durchgehen.

Diagnose mit verbose-Modus

# Maximale Detailgenauigkeit von curl
curl -vvv -x http://proxy.example.com:3128 https://api.example.com/data 2>&1 | head -50

# Worauf man im Output achten sollte:
# * Verbunden mit proxy.example.com — Verbindung zum Proxy hergestellt
# CONNECT api.example.com:443 — Tunnel-Anfrage
# HTTP/1.1 200 Connection established — Tunnel geöffnet
# * SSL-Verbindung über TLS — TLS funktioniert

# Fehlersuche mit wget
wget -d -e use_proxy=yes -e http_proxy=http://proxy.example.com:3128 https://api.example.com/data

Typische Fehler und Lösungen