cURL läuft schätzungsweise auf 20 Milliarden Installationen weltweit. Es ist standardmäßig in macOS, den meisten Linux-Distributionen und sogar in Windows 10/11 bereits enthalten. Und trotzdem bekommt man von zehn Entwicklern zehn leicht unterschiedliche Antworten, wenn man fragt, „wie man eine cURL-Anfrage sauber über einen Proxy schickt". Bei der Hälfte hakt es spätestens, sobald Authentifizierung oder SOCKS ins Spiel kommen.
Genau diese Lücke soll dieser Artikel schließen. Die meisten Anleitungen zeigen einen einzigen Befehl und tun so, als sei damit alles erledigt. Wie man aber wirklich prüft, ob der Proxy überhaupt greift, verraten sie nicht. Spoiler: Manchmal greift er gar nicht. Und über die Fehlercodes, die auftauchen, sobald die Konfiguration nur minimal vom Idealpfad abweicht, wird kaum gesprochen. Dieser Guide deckt alles ab: HTTP/HTTPS-Proxys, SOCKS4/SOCKS5/socks5h, Umgebungsvariablen und ihre Fallstricke, eine saubere Troubleshooting-Tabelle – und was zu tun ist, wenn cURL und Proxy allein am Ende nicht mehr reichen.
Was ist cURL, und warum sollte man es mit einem Proxy nutzen?
cURL ist ein Kommandozeilen-Tool, das Daten von und zu einer URL überträgt. Mehr steckt nicht dahinter. Keine grafische Oberfläche, kein Schnickschnack – einfach ein Programm, das Protokolle wie HTTP, HTTPS oder FTP spricht. Das einfachste Beispiel sieht so aus:
curl https://example.com
Dieser Befehl lädt die Seite herunter und gibt das rohe HTML direkt im Terminal aus. Das ist für sich genommen schon nützlich, aber der eigentliche Grund, warum Entwickler und technisch versierte Business-Nutzer zu cURL greifen, sind API-Tests, Web Scraping, das Prüfen geoblockter Inhalte und die Verarbeitung von Requests in CI/CD-Pipelines.
Ein Proxy schiebt sich zwischen deinen Rechner und den Zielserver und leitet die Anfrage stellvertretend weiter. Der Zielserver sieht dann nicht deine IP, sondern die des Proxys. Das ist aus ziemlich legitimen Gründen wichtig – etwa um zu prüfen, wie die eigene Seite aus einem anderen Land aussieht, um Rate Limits beim QA-Testing zu umgehen, oder um Traffic über ein vom Unternehmen vorgegebenes Gateway zu schicken. cURL unterstützt die gängigen Proxy-Protokolle HTTP, HTTPS, SOCKS4 und SOCKS5. Die Flags, die in diesem Guide immer wieder auftauchen: -x / --proxy (die Proxy-Adresse selbst), -v (Verbose-Ausgabe, beim Debuggen der beste Freund) und -k (überspringt die SSL-Prüfung – außerhalb von Tests sollte man das eigentlich nie einsetzen).
Nur damit das klar ist: Dieser Guide erklärt die technischen Abläufe beim Einsatz von cURL mit einem Proxy. Das ist kein Freifahrtschein, die Nutzungsbedingungen einer Website oder die Sicherheitsrichtlinien deines Unternehmens zu ignorieren. Ein Proxy ändert nur den Netzwerkpfad – nicht, was rechtlich oder organisatorisch erlaubt ist.
Bevor es losgeht
Schwierigkeitsgrad: Anfänger bis Fortgeschrittene
Geschätzte Dauer: ca. 15 Minuten für die Kernbeispiele
Was du brauchst:
- Prüfen, ob cURL installiert ist (mit
curl --version– auf macOS, Linux und Windows 10/11 ist es meist schon vorinstalliert) - Die Daten von deinem Proxy-Anbieter: Host, Port, Protokoll (HTTP/HTTPS/SOCKS) und, falls nötig, Benutzername/Passwort
- Ein Terminal (Terminal unter macOS, Shell unter Linux, PowerShell oder CMD unter Windows)
Falls cURL aus irgendeinem Grund doch nicht installiert ist, ist das schnell erledigt: Unter macOS mit Homebrew brew install curl, unter Debian/Ubuntu sudo apt install curl, unter RHEL/CentOS sudo yum install curl. Unter Windows ist es ab Windows 10 Build 17063 fest im Betriebssystem enthalten.
In diesem Artikel verwenden wir durchgehend proxy.example:8080 als Proxy-Adresse und user:pwd als Beispiel-Zugangsdaten. Ersetze das einfach durch deine echten Werte – aber packe echte Credentials niemals in die Shell-History, Screenshots oder Slack-Nachrichten. Ich habe ehrlich gesagt schon zu viele Proxy-Passwörter gesehen, die in Slack-Channels durchgesickert sind.
HTTP- oder HTTPS-Proxy mit cURL verwenden
Das ist die häufigste Konfiguration und die, mit der du bei den meisten Proxy-Aufgaben arbeiten wirst.
Das Flag -x / --proxy verwenden
Die Grundsyntax sieht so aus:
curl -x "http://user:pwd@proxy.example:8080" "https://httpbin.org/ip"
-x und --proxy bedeuten exakt dasselbe – nimm, was du dir besser merken kannst. HTTP ist das Standard-Proxy-Schema von cURL, theoretisch funktioniert also auch proxy.example:8080 ohne das Präfix http://. Trotzdem empfehle ich, es immer explizit hinzuschreiben. In sechs Monaten wirst du dir selbst dankbar sein, weil es so viel leichter zu lesen ist.
Setze die komplette URL immer in doppelte Anführungszeichen. Enthält das Passwort @, # oder &, kann die Shell einen nicht gequoteten String zerlegen, bevor cURL ihn überhaupt zu sehen bekommt.
Über einen HTTPS-Proxy verbinden
Manche Anbieter verschlüsseln bereits die Verbindung zum Proxy selbst mit TLS. Das heißt, nicht nur die Strecke vom Proxy zum Ziel ist verschlüsselt, sondern auch die von deinem Rechner bis zum Proxy. Das ist etwas anderes als das Scraping einer HTTPS-Seite – Proxy-Protokoll und Zielprotokoll sind voneinander unabhängig. So gibst du das an:
curl -x "https://user:pwd@proxy.example:8080" "https://httpbin.org/ip"
Wenn hier ein Zertifikatsfehler auftaucht, ist die Versuchung groß, einfach -k dranzuhängen und weiterzumachen. Aber dieses Flag schaltet die SSL-Zertifikatsprüfung komplett ab. Für einen fünfminütigen lokalen Test mag das noch angehen, in Produktionsumgebungen oder mit echten Nutzerdaten ist es keine gute Idee. Wenn du einen Unternehmens-Proxy nutzt, der TLS abfängt (MITM-Verfahren, in Enterprise-Umgebungen üblich), ist die richtige Lösung nicht, die Prüfung abzuschalten, sondern das CA-Zertifikat des Proxys zu holen und in die Vertrauenskette aufzunehmen.
Authentifizierung mit --proxy-user
Statt die Zugangsdaten in die URL zu packen, kannst du sie auch in ein eigenes Flag auslagern:
curl -x "http://proxy.example:8080" --proxy-user "user:pwd" "https://httpbin.org/ip"
Ein Punkt, auf den man achten sollte: Das große -U ist nicht dasselbe wie die Authentifizierung an der Zielseite (-u / --user, klein geschrieben). Verwechselst du die beiden, landet dein Proxy-Passwort am falschen Ort. In Unternehmensumgebungen mit NTLM- oder Digest-Authentifizierung ergänzt du --proxy-user einfach um --proxy-ntlm oder --proxy-digest.
cURL mit einem SOCKS-Proxy verwenden: SOCKS4 vs. SOCKS5 vs. socks5h
Ein SOCKS-Proxy arbeitet auf einer niedrigeren Ebene als ein HTTP-Proxy. Ihm ist ziemlich egal, welches Protokoll da getunnelt wird. Deshalb eignet er sich gut für Nicht-HTTP-Traffic, Tor-Verbindungen und Situationen, in denen Privatsphäre besonders wichtig ist. Viele andere Artikel wischen das mit einem einzigen Befehl vom Tisch – ein ziemlich großer Fehler, denn der Unterschied zwischen SOCKS4, SOCKS5 und socks5h:// ist in der Praxis wirklich relevant.
| Funktion | SOCKS4 | SOCKS5 | socks5h:// |
|---|---|---|---|
| TCP-Unterstützung | Ja | Ja | Ja |
| UDP-Unterstützung | Nein | Ja | Ja |
| Authentifizierung | Nein | Ja | Ja |
| DNS-Auflösung durch den Proxy | Nein | Nein (lokales DNS) | Ja (Proxy übernimmt) |
| Tor-kompatibel | Nein | Riskant (DNS-Leck) | Ja |
Am häufigsten stolpert man über die Zeile zur DNS-Auflösung. Bei socks5:// löst dein lokaler Rechner den Hostnamen auf, bevor die Verbindung überhaupt zum Proxy geht. Das heißt: Selbst wenn der eigentliche HTTP-Traffic über den Proxy läuft, sieht dein lokaler DNS-Resolver – und am Ende auch dein ISP –, welche Domain du ansteuerst. socks5h:// löst genau dieses Problem: Die Namensauflösung übernimmt der Proxy, sodass lokal keine Zielinformationen durchsickern. Deshalb empfiehlt die Tor-Dokumentation socks5h:// so nachdrücklich. Mit einfachem socks5:// untergräbst du einen guten Teil der Anonymität, die Tor eigentlich bieten soll.
So sehen die einzelnen Varianten in cURL aus:
curl --socks4 "proxy.example:1080" "http://example.com"
curl -x "socks5://user:pwd@proxy.example:1080" "http://example.com"
curl -x "socks5h://user:pwd@proxy.example:1080" "http://example.com"
Wenn nichts dagegenspricht, nimm socks5h:// als Standard. Es kostet nichts extra und verhindert ein Leck, das man sonst meist gar nicht bemerkt.
Proxy über Umgebungsvariablen einrichten (und die Fallstricke vermeiden)
Jedes Mal -x einzutippen, wird schnell lästig. Mit Umgebungsvariablen legst du den Proxy einmal pro Shell-Sitzung fest, und jeder folgende cURL-Aufruf übernimmt die Einstellung automatisch. Das cURL-Handbuch dokumentiert http_proxy, HTTPS_PROXY, ALL_PROXY und NO_PROXY als unterstützte Variablen.
Grundlegende Verwendung
export http_proxy="http://user:pwd@proxy.example:8080"
export HTTPS_PROXY="http://user:pwd@proxy.example:8080"
export ALL_PROXY="socks5h://proxy.example:1080"
Hier kommt es häufig zu Verwirrung: Der Variablenname richtet sich nicht nach dem Proxy-Protokoll, sondern nach dem Protokoll der Ziel-URL. http_proxy steuert also Anfragen an http://-URLs, HTTPS_PROXY steuert Anfragen an https://-URLs. Beide können ohne Weiteres auf denselben HTTP-Proxy-Server zeigen.
Mit NO_PROXY Ausnahmen definieren
export NO_PROXY="localhost,127.0.0.1,.internal.example"
Die Einträge werden mit Kommas getrennt, und der Punkt vor .internal.example wirkt wie ein Wildcard für alle Subdomains. NO_PROXY hat Vorrang vor jeder anderen Einstellung. Selbst wenn -x in der Befehlszeile steht: Trifft NO_PROXY zu, umgeht die Anfrage den Proxy trotzdem.
Die Fallstricke, die in der Praxis wirklich Probleme machen
- Das vergessene
export. Gibst du nurhttp_proxy=http://...ein, ohneexportdavorzusetzen, existiert die Variable nur in der aktuellen Shell – der Kindprozess, in dem cURL läuft, sieht sie gar nicht. Das ist aus meiner Erfahrung die häufigste Ursache für „der Proxy funktioniert einfach nicht". - Groß-/Kleinschreibung. cURL prüft ausdrücklich zuerst das kleingeschriebene
http_proxyund bevorzugt es, wenn beide Varianten existieren. Andere Tools lesen dagegen nur die Großschreibung. Wenn du debuggst, warum ein Variablenwert „nicht greift", prüfe unbedingt, ob es doppelte Variablen mit unterschiedlicher Schreibweise gibt. - Die PowerShell-Alias-Falle. In PowerShell 5.1 ruft
curlnicht das echte cURL auf, sondernInvoke-WebRequest– ein völlig anderes Tool mit anderen Flags. Wenn-xunter Windows seltsame Fehler wirft, gib explizitcurl.exean, um sicherzugehen, dass wirklich cURL läuft. - Unterschiedliche Syntax unter Windows. CMD nutzt
set http_proxy=..., PowerShell dagegen$env:http_proxy = "...". Verwechselst du das zwischen Terminal-Sitzungen, ist ein halber Tag schnell weg. - Alte Variablen, die hängen bleiben. Räume tote Proxy-Einstellungen mit
unset http_proxyundunset https_proxyauf. Sonst gehen Anfragen still und leise über den falschen Pfad raus und schlagen fehl.
Wenn du schnell umschalten willst, sparen ein paar Aliase in der .bashrc schon eine ganze Menge Zeit:
alias proxyon='export http_proxy="http://proxy.example:8080"; export https_proxy="http://proxy.example:8080"'
alias proxyoff='unset http_proxy; unset https_proxy'
cURL dauerhaft hinter einem Proxy laufen lassen (Konfigurationsdatei)
Verbringst du mehr als 95 % deiner Zeit hinter einem Unternehmens-Proxy, legt eine .curlrc-Datei (im Home-Verzeichnis unter Unix) oder eine _curlrc-Datei (im AppData-Ordner unter Windows) den Standard fest – ganz ohne Umgebungsvariablen:
proxy="http://proxy.example:8080"
Willst du den Proxy nur bei einer einzelnen Anfrage überspringen, hängst du --noproxy "*" an genau diesen Befehl an. Grundsätzlich gilt die Priorität Befehlszeilen-Flag > Umgebungsvariable > Konfigurationsdatei. Bei einem Konflikt gewinnt also immer das -x in der Befehlszeile.
Ein wichtiger Punkt: Speichere Passwörter niemals im Klartext in der .curlrc. Die Datei kann synchronisiert, gesichert oder versehentlich in ein Repository committet werden. In CI-Pipelines ist es sicherer, den Secret Manager der jeweiligen Plattform zu nutzen und Zugangsdaten über maskierte Umgebungsvariablen einzuschleusen.
So prüfst du, ob der Proxy wirklich funktioniert
Diesen Abschnitt lassen die meisten anderen Artikel aus – dabei spart er beim Debugging am meisten Zeit. Wenn du den Proxy einrichtest und einfach annimmst, „klar, darüber läuft das schon", kannst du stundenlang an einem Scraper hängen, der den Proxy von Anfang an gar nicht nutzt.
Methode 1: Die ausgehende IP vergleichen
Führe dieselbe IP-Check-Anfrage zweimal aus: einmal direkt, einmal über den Proxy, und vergleiche die Ergebnisse:
curl https://httpbin.org/ip
curl -x "http://user:pwd@proxy.example:8080" https://httpbin.org/ip
Liefern beide Befehle dieselbe IP zurück, spielt der Proxy überhaupt keine Rolle. Prüfe dann die Flag-Syntax, die Umgebungsvariablen oder ob NO_PROXY unbeabsichtigt auf das Ziel zutrifft.
Methode 2: Die Verbose-Ausgabe lesen
Hängst du bei jeder Proxy-Anfrage -v an, zeigt dir cURL den kompletten Handshake:
curl -v -x "http://user:pwd@proxy.example:8080" https://httpbin.org/ip
* Connected to proxy.example (xx.xx.xx.xx) port 8080 – achte darauf, ob danach die Zeile > CONNECT httpbin.org:443 HTTP/1.1 erscheint und am Ende < HTTP/1.1 200 Connection established. Dieser Ablauf – erst zum Proxy verbinden, dann über einen CONNECT-Tunnel das Ziel öffnen – ist der HTTP-CONNECT-Mechanismus in Aktion. Genau so sollte es aussehen, wenn ein HTTPS-Ziel über einen HTTP-Proxy angesprochen wird. Taucht die CONNECT-Zeile nie auf, greift das Proxy-Flag nicht. Nutze -v aber nur aktiv beim Debuggen und schwärze die Ausgabe unbedingt, bevor du sie teilst – im Verbose-Modus können Proxy-Zugangsdaten im Klartext auftauchen.
Methode 3: Direkter Vergleich nebeneinander
Für Geo-Tests speicherst du beide Ausgaben einfach in Dateien und vergleichst sie mit diff:
curl https://httpbin.org/ip > direct.json
curl -x "http://user:pwd@proxy.example:8080" https://httpbin.org/ip > proxied.json
diff direct.json proxied.json
Unterscheidet sich der Antwortinhalt – oder bei geoblockten Inhalten die Header –, ist das der sichtbare Beweis, dass der Proxy tatsächlich den Netzwerkpfad ändert. Eine sehr gute Methode, um einen Verdacht schnell zu klären, bevor man tiefer gräbt.
Häufige cURL-Proxy-Fehler beheben
Die meisten Anleitungen gehen hier großzügig drüber hinweg und erwähnen einmal -k – fertig. Dieses Thema braucht wirklich eine Referenztabelle.
| Fehler | Mögliche Ursache | Lösung |
|---|---|---|
curl: (7) Failed to connect | Proxy-Host/-Port falsch oder Proxy nicht erreichbar | Adresse noch einmal prüfen und die reine Verbindung mit telnet host port oder nc -zv host port testen |
407 Proxy Authentication Required | Proxy-Zugangsdaten fehlen oder sind falsch | --proxy-user user:pass ergänzen und prüfen, ob der Anbieter statt Basic NTLM/Digest/Negotiate verlangt |
curl: (56) Recv failure: Connection reset by peer | Proxy trennt die Verbindung mitten in der Übertragung | Stabilität des Anbieters prüfen; bei einem TLS-terminierenden Proxy die Zertifikatsbehandlung kontrollieren, statt die Prüfung abzuschalten |
curl: (28) Connection timed out | Firewall blockiert, veralteter Proxy oder falscher Port | Mit `env |
| Fehler bei der Zertifikatsprüfung | Nicht vertrauenswürdiges oder abfangendes Proxy-Zertifikat | Richtige CA-Kette verwenden und --proxy-cacert einsetzen; Prüfung nur für einmalige Diagnosen deaktivieren |
Der erste Schritt bei all diesen Problemen ist immer -v. Damit siehst du genau, ob es an der DNS-Auflösung, der TCP-Verbindung, dem TLS-Handshake oder der Proxy-Authentifizierung scheitert – statt aus einem dreistelligen Fehlercode raten zu müssen.
In Unternehmens-Proxy-Umgebungen kümmern sich --proxy-ntlm und --proxy-negotiate um die Windows-Domänenauthentifizierung. Eine Sache kann cURL allerdings nicht nativ verarbeiten: PAC-Dateien (Proxy Auto-Config). Manche Unternehmen weisen den Proxy per Skript dynamisch zu – cURL bringt dafür keinen PAC-Parser mit, weshalb du Host und Port manuell herausfinden musst. Meist findest du das in den Netzwerkeinstellungen des Browsers.
Wenn cURL + Proxy allein nicht mehr reichen
cURL und Proxy halten sich bei statischem HTML, REST-API-Aufrufen und einfachen Downloads ziemlich gut. Aber an den Verteidigungslinien des modernen Webs stoßen sie klar an ihre Grenzen: Single-Page-Apps, die per JavaScript gerendert werden, Anti-Bot-Systeme wie Cloudflare oder Akamai, CAPTCHA-Sperren. Richtet man cURL auf eine React- oder Vue-App hinter so einem Schutzschild, bekommt man oft nur eine leere Hülle wie <div id="root"></div> zurück. Technisch gesehen war die Anfrage erfolgreich, praktisch sind die Daten unbrauchbar. Das ist kein Bug von cURL – cURL ist kein Browser und hat auch nie behauptet, einer zu sein.
Wenn du dich im Terminal mit cURL wohlfühlst und genau an diese Grenze stößt, besteht der nächste Schritt nicht darin, das Tool komplett auszutauschen, sondern eine Schicht für Rendering und Strukturierung obendrauf zu legen. Genau diese Lücke füllen die Entwicklertools von Thunderbit.
| Szenario | cURL + Proxy | Thunderbit-API (POST /extract) |
|---|---|---|
| Statische HTML-Seite | Funktioniert einwandfrei | Funktioniert ebenfalls und liefert zusätzlich strukturierte Daten |
| JS-gerenderte SPA | Liefert leeres oder unvollständiges HTML | renderMode: "full" übernimmt das Rendering |
| Anti-Bot / CAPTCHA | Wird blockiert | Integrierte Unterstützung |
| Strukturierte Ausgabe | Rohes HTML — muss selbst geparst werden | JSON nach eigenem Schema |
| Massenverarbeitung (100+ URLs) | Manuelle Schleife + eigenes Rate Limiting | POST /batch/extract |
Die Open API von Thunderbit bietet einen /extract-Endpunkt, der auch bei JS-lastigen Seiten sofort passendes JSON nach Schema liefert, sowie einen /distill-Endpunkt für saubere Markdown-Konvertierung. Beide lassen sich aus genau der Terminal-Sitzung aufrufen, in der du gerade deine cURL-Befehle eintippst. Es gibt außerdem einen MCP-Server für KI-Coding-Assistenten wie Claude oder Cursor, und wer lieber skriptgesteuert arbeitet, kann eine CLI wie npx @thunderbit/thunderbit-cli extract <url> --schema fields.json nutzen. Das alles ersetzt nicht, worin cURL gut ist – es übernimmt genau dort, wo cURL strukturell an seine Grenzen stößt. Wer breiter verstehen will, wo KI-basierte Extraktion gegenüber eigener Scraper-Logik im Vorteil ist, findet in AI Web Scraping, den besten KI-Web-Scrapern und Web Scraping ohne eigenen Code einen guten Hintergrund, besonders aus geschäftlicher Sicht.
Fazit
cURL und Proxy sauber zum Laufen zu bringen, ist überhaupt nicht schwer, wenn man weiß, wo die Probleme typischerweise entstehen. Und überraschenderweise liegt es meistens nicht am Proxy selbst: das vergessene export, die Verwechslung von -u und -U, socks5:// statt socks5h://, der curl-Alias in PowerShell statt curl.exe. All das erzeugt kryptische, aber ziemlich verbreitete Fehler – die in Wirklichkeit oft gar nichts mit dem Proxy-Anbieter zu tun haben.
Die Gewohnheit, die am meisten Zeit spart: erst verifizieren, dann debuggen. Mach den IP-Check, wirf einen Blick auf die -v-Ausgabe, und stelle erst dann sicher, dass der Proxy wirklich im Anfragepfad liegt, bevor du tiefere Ebenen verdächtigst. Und wenn das Ziel plötzlich JavaScript statt sauberem HTML zurückgibt, ist das kein Zeichen, dass sich das mit ein paar Flags lösen lässt – das heißt, du brauchst ein Tool mit Rendering-Fähigkeit. Die API von Thunderbit bietet zum Beispiel auch einen kostenlosen Plan, mit dem sich der Unterschied zwischen JSON-Ausgabe und rohem HTML direkt ausprobieren lässt.
FAQ
Nutzt cURL standardmäßig einen Proxy?
Nein. Solange du weder die Umgebungsvariablen http_proxy / HTTPS_PROXY gesetzt noch eine .curlrc-Datei konfiguriert hast, verbindet sich cURL ohne Proxy direkt mit dem Ziel.
Wie sorge ich dafür, dass cURL bei einer bestimmten Anfrage keinen Proxy verwendet?
Häng --noproxy "*" einfach an genau diesen Befehl an. Willst du den Proxy für die gesamte Shell-Sitzung entfernen, führe unset http_proxy && unset https_proxy aus.
Kann ich cURL mit einem rotierenden Proxy verwenden?
Ja. Bietet dein Anbieter ein rotierendes Gateway – also einen einzelnen Endpunkt, der bei jeder Anfrage eine neue IP vergibt –, richtest du -x genau wie bei jedem anderen Proxy auf diese Gateway-Adresse. Brauchst du bei JS-gerenderten Zielen eine komplexere Rotationslogik, übernimmt eine API-Schicht wie Thunderbit Rotation und Anti-Bot-Handling intern, sodass du keine eigene Retry-Logik pflegen musst.
Warum leckt socks5:// DNS-Anfragen, socks5h:// aber nicht?
socks5:// löst deinen lokalen Zielhostnamen auf, bevor die Verbindungsanfrage überhaupt rausgeht. Der DNS-Resolver deines ISPs sieht also, welche Domain du ansteuerst. socks5h:// dagegen überlässt die Namensauflösung dem Proxy selbst, sodass lokal keine Zielinformationen preisgegeben werden.
Ist es legal, cURL mit einem Proxy zu verwenden?
Die Nutzung eines Proxys an sich ist in den meisten Rechtsordnungen grundsätzlich legal. Entscheidend ist, wofür du ihn einsetzt. Halte dich immer an die Nutzungsbedingungen der Zielseite, gegebenenfalls die robots.txt und die geltenden Datenschutzgesetze. Dieser Guide behandelt ausschließlich die technische Seite und gibt keine umfassende Garantie für die rechtliche Zulässigkeit eines bestimmten Anwendungsfalls.
Mehr erfahren
