Proxys in GitHub Actions und CI/CD-Pipelines: Umfassender Leitfaden mit Codebeispielen

```html

GitHub Actions ist ein leistungsstarkes Automatisierungstool: Es führt Tests durch, deployt Anwendungen, sammelt Daten und erledigt Dutzende anderer Aufgaben. Doch sobald der Workflow externe Ressourcen ansteuert – Marktplätze, Werbeplattformen, ausländische APIs – stößt er sofort auf Geobeschränkungen und IP-Limits. Die Lösung ist einfach: Verbinden Sie einen Proxy direkt im Pipeline.

Warum Proxys in GitHub Actions: reale Szenarien

Viele Teams nutzen GitHub Actions nicht nur für das Deployen von Code, sondern auch zur Automatisierung von Geschäftsaufgaben: Überwachung von Wettbewerberpreisen, Datensammlung von Marktplätzen, automatische Überprüfung von Werbekonten und Tests von Websites aus verschiedenen Regionen. All diese Aufgaben haben ein gemeinsames Problem – der GitHub Actions Runner hat eine feste IP aus dem Microsoft Azure-Bereich, und viele Dienste blockieren oder schränken ihn ein.

Hier sind konkrete Situationen, in denen man ohne Proxy nicht auskommt:

• Scraping von Wildberries, Ozon, Avito – diese Plattformen haben die IP-Bereiche von Cloud-Anbietern längst auf schwarze Listen gesetzt. Anfragen vom GitHub Actions Runner werden bereits nach 2–3 Versuchen blockiert oder erhalten ein Captcha.
• Geotargeting-Tests – Marketer und QA-Ingenieure überprüfen, wie die Website oder Werbung für Nutzer aus Moskau, Berlin oder New York aussieht. Ohne Proxy sieht der Runner immer nur den Inhalt für eine Region.
• Arbeiten mit regional eingeschränkten APIs – einige APIs (z. B. regionale Versionen von Google Ads, Facebook Marketing API mit bestimmten Einstellungen) geben je nach Geolocation der Anfrage unterschiedliche Daten zurück.
• Überwachung von Wettbewerbern – die automatische Sammlung von Preisen, Aktionen und Sortimenten erfordert regelmäßige Anfragen, die leicht anhand der wiederholten IP des Rechenzentrums erkannt werden können.
• Automatisierung von Werbeprüfungen – Arbitrageure und Performance-Marketer führen automatische Überprüfungen des Status von Anzeigen, Bilanzen und Metriken über Skripte in CI/CD durch.
• Integrationstests mit externen Diensten – einige Dienste blockieren Anfragen aus Azure-Bereichen aus Sicherheitsgründen, und die Tests schlagen einfach ohne Erklärung fehl.

In all diesen Fällen löst ein Proxy das Problem radikal: Der Workflow sieht aus wie eine Anfrage von einem normalen Benutzer aus der gewünschten Stadt und nicht von einem Cloud-Server von Microsoft.

Wie GitHub Actions mit dem Netzwerk funktioniert

Bevor Sie einen Proxy einrichten, ist es wichtig, die Netzwerkarchitektur in GitHub Actions zu verstehen. Wenn Sie einen Workflow auf einem Standard-ubuntu-latest Runner starten, wird die Aufgabe auf einer virtuellen Maschine in der Microsoft Azure-Infrastruktur ausgeführt. Jede dieser Maschinen hat eine öffentliche IP aus den Azure-Bereichen – und genau diese IP sehen externe Dienste.

Wichtige Merkmale des Netzwerks in GitHub Actions:

• IP ändert sich bei jedem Start – bleibt aber innerhalb der bekannten Azure-Bereiche, die leicht erkannt werden können.
• Keine eingebaute Unterstützung für Proxys – GitHub bietet keinen nativen Mechanismus zur Proxyierung des Traffics.
• Umgebungsvariablen wirken global – wenn HTTP_PROXY auf Job-Ebene gesetzt wird, verwenden alle Schritte innerhalb dieses Jobs den Proxy.
• Self-hosted Runners – eine Alternative, bei der Sie den Runner auf Ihrem eigenen Server ausführen. In diesem Fall wird der Proxy auf Server-Ebene und nicht auf Workflow-Ebene eingerichtet.

Für die meisten Aufgaben ist der optimale Ansatz die Einrichtung des Proxys über Umgebungsvariablen direkt in der Workflow-Datei (.github/workflows/your-workflow.yml). Dies ist eine universelle Methode, die für die meisten Tools funktioniert: curl, wget, Python requests, Node.js http, Go net/http und andere.

Welchen Proxy-Typ für CI/CD wählen

Die Wahl des Proxy-Typs hängt von der Aufgabe ab. Für CI/CD-Pipelines sind drei Varianten relevant, und jede hat ihre Nische:

Praktische Regel: Wenn Ihr Workflow Wildberries, Ozon oder andere Marktplätze mit Anti-Bot-Schutz scrapt – verwenden Sie Residential Proxys. Wenn Sie Werbekonten von Facebook Ads oder TikTok Ads testen – verwenden Sie mobile Proxys. Für einfache Integrationstests und Anfragen an offene APIs genügen Datacenter Proxys: sie sind schneller und günstiger.

Proxy über Umgebungsvariablen einrichten

Der universellste Weg, einen Proxy in GitHub Actions zu verbinden, besteht darin, die Standard-Umgebungsvariablen HTTP_PROXY, HTTPS_PROXY und NO_PROXY zu setzen. Die meisten Kommandozeilen-Tools und Programmiersprachen erfassen sie automatisch.

Die grundlegende Struktur eines Workflows mit Proxy sieht so aus:

name: Workflow mit Proxy

on:
  schedule:
    - cron: '0 9 * * *'
  workflow_dispatch:

jobs:
  scrape-data:
    runs-on: ubuntu-latest

    env:
      HTTP_PROXY: http://${{ secrets.PROXY_USER }}:${{ secrets.PROXY_PASS }}@${{ secrets.PROXY_HOST }}:${{ secrets.PROXY_PORT }}
      HTTPS_PROXY: http://${{ secrets.PROXY_USER }}:${{ secrets.PROXY_PASS }}@${{ secrets.PROXY_HOST }}:${{ secrets.PROXY_PORT }}
      NO_PROXY: localhost,127.0.0.1,github.com

    steps:
      - name: Repository auschecken
        uses: actions/checkout@v4

      - name: Aktuelle IP überprüfen (zur Überprüfung)
        run: curl -s https://api.ipify.org

      - name: Hauptskript ausführen
        run: python scripts/scraper.py

Beachten Sie den Block NO_PROXY – hier müssen die Adressen hinzugefügt werden, für die der Traffic nicht über den Proxy geleitet werden soll. Mindestens sollten dies localhost und 127.0.0.1 sein. Es wird auch empfohlen, github.com hinzuzufügen, damit die Operationen mit dem Repository (Checkout, Push) direkt erfolgen.

Wenn der Proxy keine Authentifizierung benötigt (nur IP und Port), vereinfacht sich das Format:

env:
  HTTP_PROXY: http://203.0.113.10:8080
  HTTPS_PROXY: http://203.0.113.10:8080
  NO_PROXY: localhost,127.0.0.1

Für SOCKS5-Proxys ändert sich nur das Schema in der URL:

env:
  HTTP_PROXY: socks5://user:password@proxy-host:1080
  HTTPS_PROXY: socks5://user:password@proxy-host:1080

Proxys für curl, wget und HTTP-Anfragen in der Shell

Wenn die Umgebungsvariablen auf Job-Ebene gesetzt sind (wie oben gezeigt), erfassen curl und wget sie automatisch. Manchmal muss der Proxy jedoch explizit angegeben werden – zum Beispiel für einen bestimmten Schritt oder zur Fehlersuche.

Explizite Angabe des Proxys in curl:

- name: Daten mit Proxy abrufen
  run: |
    curl -x http://${{ secrets.PROXY_USER }}:${{ secrets.PROXY_PASS }}@${{ secrets.PROXY_HOST }}:${{ secrets.PROXY_PORT }} \
      -s \
      -o output.json \
      https://api.example.com/data

    # Überprüfung über den Proxy
    curl -x http://${{ secrets.PROXY_USER }}:${{ secrets.PROXY_PASS }}@${{ secrets.PROXY_HOST }}:${{ secrets.PROXY_PORT }} \
      -s https://api.ipify.org?format=json

Für wget:

- name: Mit wget über Proxy herunterladen
  run: |
    wget -e "https_proxy=http://${{ secrets.PROXY_USER }}:${{ secrets.PROXY_PASS }}@${{ secrets.PROXY_HOST }}:${{ secrets.PROXY_PORT }}" \
      -q \
      -O data.html \
      https://target-site.com/page

Ein nützlicher Schritt zur Fehlersuche ist es, zu Beginn des Workflows die IP-Adresse zu überprüfen. Wenn der Proxy korrekt funktioniert, sehen Sie die IP des Proxy-Servers und nicht die von Azure:

- name: Überprüfen, ob der Proxy aktiv ist
  run: |
    echo "=== IP ohne Proxy ==="
    curl -s --noproxy '*' https://api.ipify.org || echo "Direkte Anfrage fehlgeschlagen"
    echo ""
    echo "=== IP über Proxy ==="
    curl -s https://api.ipify.org

Proxys in Python-Skripten innerhalb des Workflows

Python ist eine der beliebtesten Sprachen für Skripte in CI/CD. Die Bibliothek requests liest automatisch die Umgebungsvariablen HTTP_PROXY und HTTPS_PROXY, wenn sie gesetzt sind. Für eine flexiblere Steuerung ist es jedoch besser, den Proxy explizit zu übergeben.

Beispiel eines Python-Skripts mit expliziter Übergabe des Proxys über Umgebungsvariablen:

import os
import requests

# Proxy-Daten aus Umgebungsvariablen lesen
proxy_host = os.environ.get('PROXY_HOST')
proxy_port = os.environ.get('PROXY_PORT')
proxy_user = os.environ.get('PROXY_USER')
proxy_pass = os.environ.get('PROXY_PASS')

proxies = {
    'http': f'http://{proxy_user}:{proxy_pass}@{proxy_host}:{proxy_port}',
    'https': f'http://{proxy_user}:{proxy_pass}@{proxy_host}:{proxy_port}',
}

# Proxy in der Anfrage verwenden
response = requests.get(
    'https://www.wildberries.ru/catalog/123456/detail.aspx',
    proxies=proxies,
    timeout=30,
    headers={
        'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36'
    }
)

print(f"Status: {response.status_code}")
print(f"Inhaltslänge: {len(response.content)}")

In der Workflow-Datei müssen die Variablen als separate Secrets übergeben werden (nicht als vollständige URL), damit das Skript sie sammeln kann:

- name: Python-Scraper ausführen
  env:
    PROXY_HOST: ${{ secrets.PROXY_HOST }}
    PROXY_PORT: ${{ secrets.PROXY_PORT }}
    PROXY_USER: ${{ secrets.PROXY_USER }}
    PROXY_PASS: ${{ secrets.PROXY_PASS }}
  run: python scripts/scraper.py

Für die Arbeit mit Playwright oder Selenium in Python ist die Proxy-Konfiguration etwas anders:

# Playwright
from playwright.sync_api import sync_playwright
import os

proxy_url = f"http://{os.environ['PROXY_USER']}:{os.environ['PROXY_PASS']}@{os.environ['PROXY_HOST']}:{os.environ['PROXY_PORT']}"

with sync_playwright() as p:
    browser = p.chromium.launch(
        proxy={
            "server": proxy_url
        }
    )
    page = browser.new_page()
    page.goto("https://target-site.com")
    # ... weitere Logik
    browser.close()

Proxys in Node.js und npm-Tasks

Node.js liest die Systemvariablen HTTP_PROXY nicht automatisch – Sie müssen entweder spezielle Bibliotheken verwenden oder den Proxy explizit einrichten. Die bequemste Option ist das Paket https-proxy-agent oder axios mit Proxy-Konfiguration.

// Mit axios
const axios = require('axios');

const proxyConfig = {
  host: process.env.PROXY_HOST,
  port: parseInt(process.env.PROXY_PORT),
  auth: {
    username: process.env.PROXY_USER,
    password: process.env.PROXY_PASS
  }
};

async function fetchData(url) {
  try {
    const response = await axios.get(url, {
      proxy: proxyConfig,
      timeout: 30000,
      headers: {
        'User-Agent': 'Mozilla/5.0 (compatible; MyBot/1.0)'
      }
    });
    return response.data;
  } catch (error) {
    console.error(`Anfrage fehlgeschlagen: ${error.message}`);
    throw error;
  }
}

fetchData('https://api.example.com/prices')
  .then(data => console.log(JSON.stringify(data, null, 2)))
  .catch(() => process.exit(1));

Für npm-Befehle (zum Beispiel, wenn npm versucht, Pakete über einen Unternehmensproxy herunterzuladen) ist die Konfiguration einfacher:

- name: npm-Proxy konfigurieren
  run: |
    npm config set proxy http://${{ secrets.PROXY_USER }}:${{ secrets.PROXY_PASS }}@${{ secrets.PROXY_HOST }}:${{ secrets.PROXY_PORT }}
    npm config set https-proxy http://${{ secrets.PROXY_USER }}:${{ secrets.PROXY_PASS }}@${{ secrets.PROXY_HOST }}:${{ secrets.PROXY_PORT }}

- name: Abhängigkeiten installieren
  run: npm install

- name: npm-Proxy zurücksetzen (nach Verwendung löschen)
  run: |
    npm config delete proxy
    npm config delete https-proxy

Sichere Speicherung von Proxy-Daten in GitHub Secrets

Speichern Sie niemals Proxy-Daten (Host, Port, Benutzername, Passwort) direkt in der Workflow-Datei im Klartext. Dies ist ein schwerwiegender Sicherheitsfehler: Workflow-Dateien werden im Repository gespeichert und können von allen Projektmitgliedern oder sogar öffentlich eingesehen werden.

Der richtige Ansatz sind GitHub Secrets. Hier ist eine Schritt-für-Schritt-Anleitung:

1. Öffnen Sie das Repository auf GitHub
2. Gehen Sie zu Settings → Secrets and variables → Actions
3. Klicken Sie auf New repository secret
4. Erstellen Sie vier Secrets: PROXY_HOST, PROXY_PORT, PROXY_USER, PROXY_PASS
5. Greifen Sie in Ihrem Workflow über die Syntax ${{ secrets.PROXY_HOST }} auf sie zu

Wenn Sie rotierende Proxys verwenden (wenn sich die IP bei jeder Anfrage oder nach Zeitplan ändert), reicht es oft aus, nur einen Endpunkt zu speichern – der Proxy-Anbieter verwaltet selbst den Pool von IPs. In diesem Fall gibt es in den Secrets nur einen Host und Port des Rotationsgateways.

Proxy-Rotation und Fehlerbehandlung im Pipeline

Selbst hochwertige Proxys können manchmal ausfallen: Die IP kann in ein temporäres Verbot geraten, die Sitzung kann abgebrochen werden, der Server kann nicht antworten. Für CI/CD-Pipelines, die automatisch ohne Aufsicht arbeiten, ist es wichtig, solche Situationen zu berücksichtigen.

Strategie 1: Retry mit demselben Proxy

import requests
import time
import os

def fetch_with_retry(url, max_retries=3, delay=5):
    proxies = {
        'http': f"http://{os.environ['PROXY_USER']}:{os.environ['PROXY_PASS']}@{os.environ['PROXY_HOST']}:{os.environ['PROXY_PORT']}",
        'https': f"http://{os.environ['PROXY_USER']}:{os.environ['PROXY_PASS']}@{os.environ['PROXY_HOST']}:{os.environ['PROXY_PORT']}",
    }

    for attempt in range(max_retries):
        try:
            response = requests.get(url, proxies=proxies, timeout=30)
            response.raise_for_status()
            return response
        except requests.exceptions.RequestException as e:
            print(f"Versuch {attempt + 1} fehlgeschlagen: {e}")
            if attempt < max_retries - 1:
                print(f"Erneuter Versuch in {delay} Sekunden...")
                time.sleep(delay)
                delay *= 2  # Exponentielle Verzögerung
    raise Exception(f"Alle {max_retries} Versuche für {url} fehlgeschlagen")

Strategie 2: Liste von Proxys mit Umschaltung

Wenn Sie mehrere Proxy-Server haben, können Sie deren Liste in einem Secret (durch Kommas getrennt) speichern und bei einem Fehler umschalten:

import os
import requests
import random

# Secret PROXY_LIST enthält: "host1:port1:user1:pass1,host2:port2:user2:pass2"
proxy_list_raw = os.environ.get('PROXY_LIST', '').split(',')

def parse_proxy(proxy_str):
    parts = proxy_str.strip().split(':')
    if len(parts) == 4:
        host, port, user, password = parts
        return {
            'http': f'http://{user}:{password}@{host}:{port}',
            'https': f'http://{user}:{password}@{host}:{port}',
        }
    return None

proxies = [p for p in [parse_proxy(raw) for raw in proxy_list_raw] if p]

def fetch_with_proxy_rotation(url):
    random.shuffle(proxies)  # Zufällige Reihenfolge
    for proxy in proxies:
        try:
            response = requests.get(url, proxies=proxy, timeout=20)
            if response.status_code == 200:
                return response
        except Exception as e:
            print(f"Proxy fehlgeschlagen: {e}, versuche den nächsten...")
    raise Exception("Alle Proxys erschöpft")

Strategie 3: Verwendung eines rotierenden Endpunkts

Die einfachste Option ist die Verwendung eines Proxy-Anbieters mit einem einzigen rotierenden Gateway. In diesem Fall verbinden Sie sich mit einer Adresse, und der Anbieter gibt automatisch verschiedene IPs aus dem Pool aus. Es ist keine Logik zur Rotation im Code erforderlich – eine einzige Verbindungszeile reicht aus.

Reale Szenarien: Scraping, Tests, Preisüberwachung

Lassen Sie uns drei konkrete Szenarien betrachten, die am häufigsten bei Teams auftreten, die GitHub Actions mit Proxys verwenden.

Szenario 1: Tägliche Preisüberwachung auf Wildberries

Verkäufer auf Marktplätzen richten häufig eine automatische Sammlung von Wettbewerberpreisen ein. Der Workflow wird nach Zeitplan gestartet (zum Beispiel jeden Morgen um 7:00 Uhr), sammelt Daten und speichert sie in Google Sheets oder sendet sie an Telegram.

name: Täglicher Preismonitor

on:
  schedule:
    - cron: '0 4 * * *'  # 07:00 MSK (UTC+3)

jobs:
  monitor-prices:
    runs-on: ubuntu-latest

    env:
      HTTP_PROXY: http://${{ secrets.PROXY_USER }}:${{ secrets.PROXY_PASS }}@${{ secrets.PROXY_HOST }}:${{ secrets.PROXY_PORT }}
      HTTPS_PROXY: http://${{ secrets.PROXY_USER }}:${{ secrets.PROXY_PASS }}@${{ secrets.PROXY_HOST }}:${{ secrets.PROXY_PORT }}
      NO_PROXY: github.com,api.github.com

    steps:
      - uses: actions/checkout@v4

      - name: Python einrichten
        uses: actions/setup-python@v5
        with:
          python-version: '3.11'

      - name: Abhängigkeiten installieren
        run: pip install requests beautifulsoup4 gspread

      - name: Preis-Scraper ausführen
        env:
          GOOGLE_SHEETS_KEY: ${{ secrets.GOOGLE_SHEETS_KEY }}
          TELEGRAM_BOT_TOKEN: ${{ secrets.TELEGRAM_BOT_TOKEN }}
          TELEGRAM_CHAT_ID: ${{ secrets.TELEGRAM_CHAT_ID }}
        run: python scripts/price_monitor.py

      - name: Ergebnisse als Artefakt hochladen
        uses: actions/upload-artifact@v4
        with:
          name: price-data-${{ github.run_id }}
          path: output/prices.json

Szenario 2: Geotargeting-Tests der Website

Marketer und QA-Teams verwenden Proxys, um zu überprüfen, wie die Website oder Werbung für Nutzer aus verschiedenen Städten aussieht. Besonders relevant für die Überprüfung regionaler Preise, Inhalte und Weiterleitungen.

name: Geotargeting-Website-Tests

on:
  push:
    branches: [main]
  pull_request:

jobs:
  test-moscow:
    runs-on: ubuntu-latest
    name: Test aus Moskau
    steps:
      - uses: actions/checkout@v4
      - name: Geotests ausführen (RU/Moskau-Proxy)
        env:
          HTTP_PROXY: http://${{ secrets.PROXY_RU_USER }}:${{ secrets.PROXY_RU_PASS }}@${{ secrets.PROXY_RU_HOST }}:${{ secrets.PROXY_RU_PORT }}
          HTTPS_PROXY: http://${{ secrets.PROXY_RU_USER }}:${{ secrets.PROXY_RU_PASS }}@${{ secrets.PROXY_RU_HOST }}:${{ secrets.PROXY_RU_PORT }}
        run: |
          python tests/geo_test.py --region=RU --city=Moscow

  test-germany:
    runs-on: ubuntu-latest
    name: Test aus Deutschland
    steps:
      - uses: actions/checkout@v4
      - name: Geotests ausführen (DE-Proxy)
        env:
          HTTP_PROXY: http://${{ secrets.PROXY_DE_USER }}:${{ secrets.PROXY_DE_PASS }}@${{ secrets.PROXY_DE_HOST }}:${{ secrets.PROXY_DE_PORT }}
          HTTPS_PROXY: http://${{ secrets.PROXY_DE_USER }}:${{ secrets.PROXY_DE_PASS }}@${{ secrets.PROXY_DE_HOST }}:${{ secrets.PROXY_DE_PORT }}
        run: |
          python tests/geo_test.py --region=DE

Szenario 3: Automatische Überprüfung von Werbekonten

Arbitrageure und Performance-Marketer verwenden häufig GitHub Actions zur automatischen Überprüfung des Status von Facebook Ads-Werbekonten, Bilanzen und Metriken. Anfragen an die Facebook Marketing API aus Azure-Bereichen können zusätzliche Sicherheitsüberprüfungen auslösen – Proxys helfen, dies zu umgehen.

name: Überprüfung der Werbekontogesundheit

on:
  schedule:
    - cron: '*/30 6-22 * * *'  # Alle 30 Minuten von 6 bis 22 MSK

jobs:
  check-accounts:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Python einrichten
        uses: actions/setup-python@v5
        with:
          python-version: '3.11'

      - name: Abhängigkeiten installieren
        run: pip install requests

      - name: Facebook Ads-Konten überprüfen
        env:
          HTTP_PROXY: http://${{ secrets.PROXY_USER }}:${{ secrets.PROXY_PASS }}@${{ secrets.PROXY_HOST }}:${{ secrets.PROXY_PORT }}
          HTTPS_PROXY: http://${{ secrets.PROXY_USER }}:${{ secrets.PROXY_PASS }}@${{ secrets.PROXY_HOST }}:${{ secrets.PROXY_PORT }}
          FB_ACCESS_TOKEN: ${{ secrets.FB_ACCESS_TOKEN }}
          ACCOUNT_IDS: ${{ secrets.FB_ACCOUNT_IDS }}
          TELEGRAM_BOT_TOKEN: ${{ secrets.TELEGRAM_BOT_TOKEN }}
          TELEGRAM_CHAT_ID: ${{ secrets.TELEGRAM_CHAT_ID }}
        run: python scripts/check_fb_accounts.py

Fazit

Die Einrichtung eines Proxys in GitHub Actions ist keine schwierige Aufgabe, wenn man den richtigen Ansatz kennt. Die wichtigsten Erkenntnisse aus diesem Leitfaden:

• Umgebungsvariablen HTTP_PROXY / HTTPS_PROXY – eine universelle Methode, die für die meisten Tools ohne Codeänderung funktioniert.
• GitHub Secrets – der einzig richtige Ort zur Speicherung von Proxy-Anmeldeinformationen.
• Der Proxy-Typ ist wichtig: Für das Scraping geschützter Marktplätze sind Residential IPs erforderlich, für Werbeplattformen mobile Proxys, für einfache API-Anfragen genügen Datacenter Proxys.
• Retry-Logik ist obligatorisch für Pipelines, die ohne Aufsicht nach Zeitplan arbeiten.
• Ein Schritt zur IP-Überprüfung zu Beginn des Workflows spart Stunden an Fehlersuche.

Wenn Ihr GitHub Actions Workflow mit Marktplätzen, Werbeplattformen oder anderen Diensten mit Anti-Bot-Schutz arbeitet, empfehlen wir die Verwendung von Residential Proxys – sie haben echte IPs von Haushaltsnutzern und verursachen deutlich seltener Blockierungen im Vergleich zu den Cloud-Adressen von GitHub-Servern. Für Aufgaben, die mit Facebook Ads, TikTok oder anderen sozialen Plattformen zu tun haben, sind mobile Proxys mit Betreiber-IP die optimale Wahl – sie bieten das höchste Vertrauensniveau seitens der Plattformen.