Inhalt des Artikels

Der Satz „Der Proxy funktioniert nicht“ klingt für einen Support-Ingenieur ungefähr wie „Es tut irgendwo innerlich weh“ für einen Arzt. Die Richtung ist klar, aber ohne Tests und Symptome kann keine Diagnose gestellt werden. In dieser Anleitung lernen Sie, genau die Datenmenge zu sammeln, die eine vage Beschwerde in eine konkrete Aufgabe mit einer klaren Antwort verwandelt.

Einleitung: Warum „funktioniert nicht“ nicht diagnostiziert werden kann

Stellen Sie sich zwei Anfragen an den Proxeon-Support vor. Die erste: „Ich habe einen Proxy gekauft, nichts funktioniert, helfen Sie mir.“ Die zweite: „Der Proxy mit der ID PX-48213 gibt um 14:32 MSK (UTC+3) einen Verbindungsfehler bei einer Anfrage an api.example.com über HTTP aus, während derselbe Proxy bei einer anderen Website funktioniert, die direkte Verbindung ohne Proxy ebenfalls funktioniert, curl-Ausgabe füge ich bei.“ Die erste Anfrage startet eine Kette von fünf bis sechs Klärungs-E-Mails, von denen jede Stunden Wartezeit kostet. Die zweite wird mit einer einzigen Antwort geschlossen.

Der Unterschied liegt nicht in Höflichkeit und nicht im Glück. Der Unterschied liegt in den Daten. Der Ingenieur sieht Ihren Bildschirm nicht, kennt Ihr Betriebssystem nicht und kann Ihre Anfrage ohne Ausgangsparameter nicht reproduzieren. Alles, was er hat, ist der Text Ihrer E-Mail. Wenn in diesem Text keine Fakten stehen, wird er als Erstes Fakten anfordern. Das ist genau diese E-Mail-Kette, die die Lösung eines einfachen Problems auf mehrere Tage streckt.

Was der Leser am Ende erhält

Nach dieser Anleitung können Sie in 15–20 Minuten ein Diagnosepaket zusammenstellen, das alles enthält, was zur Lösung des Problems mit der ersten Antwort nötig ist. Sie haben ein fertiges Skript, das technische Daten in eine Textdatei sammelt, eine Anfragevorlage zum Kopieren und ein klares Verständnis davon, welche Prüfungen durchgeführt werden müssen, bevor Sie den Support kontaktieren.

Für wen dieser Leitfaden ist

Die Anleitung richtet sich an Proxy-Nutzer mittleren Niveaus: diejenigen, die ein Terminal oder eine Eingabeaufforderung öffnen können, wissen, was eine URL ist, und mindestens einmal einen Proxy in einer Anwendung eingerichtet haben. Fortgeschrittene Nutzer finden hier ein fertiges Diagnoseskript und eine Tabelle zur Problemisolierung. Anfängern erklären wir jeden Begriff ausführlich.

Was Sie im Voraus wissen müssen

Es reicht, drei Dinge zu verstehen. Proxy — das ist ein Vermittler, über den Ihre Netzwerkanfrage läuft. Zieladresse — die Website oder der Dienst, den Sie ansprechen. Client — das Programm, das die Anfrage über den Proxy stellt (Browser, Parser, Skript). Alles andere klären wir im Verlauf.

Wie viel Zeit benötigt wird

Der erste Durchlauf durch die Anleitung mit der Einrichtung des Skripts dauert etwa 30 Minuten. Danach dauert das Sammeln der Diagnose nach der fertigen Vorlage 10–15 Minuten. Das ist unvergleichlich weniger als mehrere Tage E-Mail-Korrespondenz mit Rückfragen.

Tipp: Speichern Sie diese Anleitung und das Skript als Lesezeichen. Proxy-Probleme treten selten auf, und wenn sie auftreten, ist es schwer, sich die gesamte Prozedur wieder ins Gedächtnis zu rufen. Eine fertige Checkliste zur Hand spart Nerven.

Vorbereitung: Werkzeuge und Zugänge

Bevor Sie Daten sammeln, stellen Sie sicher, dass Sie über die grundlegenden Werkzeuge verfügen. Alle sind kostenlos und in den meisten Systemen bereits installiert.

Erforderliche Werkzeuge

  • curl — ein Kommandozeilen-Dienstprogramm zum Senden von Netzwerkanfragen. Das ist unser Hauptwerkzeug zur Reproduktion des Problems. In macOS und den meisten Linux-Distributionen ist es vorinstalliert. In Windows 10 und 11 ist es ebenfalls Teil des Systems.
  • Terminal oder Eingabeaufforderung — das Fenster, in dem Sie Befehle eingeben. In Windows ist das PowerShell oder die Eingabeaufforderung (cmd), in macOS und Linux das Terminal.
  • Texteditor — Notepad, TextEdit oder ein anderer zum Anzeigen der gesammelten Datei und zum Entfernen von Geheimnissen.
  • Ihre Proxeon-Proxy-Daten — ID, Adresse, Port, Login und Passwort. Diese wurden Ihnen im Kundenbereich ausgegeben.

Überprüfung der curl-Verfügbarkeit

Öffnen Sie das Terminal und führen Sie eine einfache Prüfung durch.

  1. Drücken Sie in Windows die Win-Taste, geben Sie PowerShell ein und öffnen Sie die Anwendung.
  2. Öffnen Sie in macOS Spotlight mit Cmd+Leertaste, geben Sie Terminal ein und drücken Sie Enter.
  3. Öffnen Sie in Linux das Terminal über das Anwendungsmenü oder mit Ctrl+Alt+T.
  4. Geben Sie den Befehl 
    curl --version
    ein und drücken Sie Enter.

Wenn Sie eine Zeile wie „curl 8.x.x“ mit einer Liste unterstützter Protokolle sehen, ist das Werkzeug bereit. Wenn das System meldet, dass der Befehl nicht gefunden wurde, installieren Sie curl: In Windows aktualisieren Sie das System auf die aktuelle Version, in Linux führen Sie die Installation über den Paketmanager Ihrer Distribution durch.

✅ Prüfung: Der Befehl 

curl --version
hat eine Versionsnummer und eine Liste der Protokolle, einschließlich http und https, ausgegeben. Das bedeutet, alles ist bereit für die Arbeit.

Welche Proxeon-Daten vorzubereiten sind

Gehen Sie in Ihren Proxeon-Kundenbereich auf proxeon.net und öffnen Sie die Karte Ihres Proxys. Notieren oder kopieren Sie die folgenden Felder in eine separate Datei: Proxy-ID, Host (Adresse), Port, Typ (HTTP, HTTPS oder SOCKS5), Login und Passwort. Diese Daten werden für die Erstellung des Reproduktionsbefehls benötigt.

⚠️ Achtung: Login und Passwort für den Proxy sind geheime Daten. Wir werden lokal damit arbeiten, aber sie dürfen NICHT in die Support-Anfrage eingefügt werden. Unten gibt es einen separaten Abschnitt darüber, wie man Logs vor dem Versenden sicher bereinigt.

Grundbegriffe: Die Grenze Client — Proxy — Server

Um zu verstehen, welche Daten wichtig sind, muss man sich den Weg der Anfrage vorstellen. Sie durchläuft drei Abschnitte, und das Problem kann an jedem von ihnen auftreten.

Drei Glieder einer Kette

Wenn Sie eine Website über einen Proxy ansprechen, läuft die Anfrage so: Ihr Client sendet eine Anfrage an den Proxy-Server, dieser leitet sie an den Zielserver weiter, erhält die Antwort und gibt sie an Sie zurück. Drei Glieder, zwei Grenzen. Zu verstehen, an welcher Grenze es hakt, ist die halbe Diagnose.

  • Grenze Client — Proxy. Wenn die Anfrage nicht einmal den Proxy erreicht hat, liegt das Problem auf Ihrer Seite: falsche Proxy-Adresse, geschlossener Port, Unternehmensfilter, Fehler in den Client-Einstellungen.
  • Grenze Proxy — Server. Wenn der Proxy die Anfrage angenommen hat, aber die Zielwebsite nicht erreichen konnte, liegt das Problem zwischen Proxy und Ziel: Website nicht verfügbar, lehnt die Verbindung ab oder antwortet mit einem Fehler.

Die Aufgabe der Diagnose ist es, festzustellen, an welcher Grenze alles zusammengebrochen ist. Der Proxeon-Support-Ingenieur sieht an Ihrer Ausgabe sofort, wo die Anfrage gestoppt wurde, und das grenzt den Kreis der Ursachen stark ein.

Warum die genaue Uhrzeit so wichtig ist

Die Proxy-Infrastruktur führt Logs. Um Ihre konkrete Anfrage darin zu finden, benötigt der Ingenieur die genaue Uhrzeit des Ereignisses mit Angabe der Zeitzone. „Heute Morgen“ lässt sich in Logs nicht suchen. „14:32 MSK, UTC+3“ lässt sich in Sekunden finden. Der Zeitunterschied zwischen Ihrer Formulierung und dem Eintrag im Log ist eine häufige Ursache dafür, dass das Ereignis gar nicht gefunden wird.

Tipp: Geben Sie immer die Zeitzone explizit an. Das Format „UTC+3“ oder „MSK“ ist ohne Vermutungen verständlich. Wenn Sie in einer anderen Zeitzone sind, geben Sie Ihre an — der Server rechnet selbst um.

Schritt 1: Den minimalen Datensatz sammeln

Ziel der Etappe: Fünf Fakten festhalten, ohne die jede Anfrage unvollständig bleibt. Das ist das Fundament, alles andere baut darauf auf.

Fünf Pflichtfakten

  1. Proxy-ID. Der genaue Name oder die Nummer aus dem Proxeon-Kundenbereich, zum Beispiel PX-48213. Nicht „der Proxy, den ich gestern gekauft habe“, sondern eine konkrete ID. Wenn Sie ein Paket mit mehreren Proxys haben, geben Sie an, um welchen es geht.
  2. Genaue Uhrzeit mit Zeitzone. Wann genau das Problem aufgetreten ist. Format: Datum, Uhrzeit, Zone. Zum Beispiel: 12. März 2026, 14:32, UTC+3. Wenn das Problem wiederholt auftritt, geben Sie mehrere Zeitstempel an.
  3. Zieladresse. Die vollständige URL oder der Host, den Sie angesprochen haben. Zum Beispiel: https://api.example.com/v2/data. Nicht „eine Website“, sondern die genaue Adresse.
  4. Was genau Sie getan haben. Ein bis zwei Sätze zur Aktion. „Ich habe eine GET-Anfrage aus meinem Skript gesendet“ oder „Ich habe die Website im Browser mit konfiguriertem Proxy geöffnet“. Der Kontext hilft, die Art der Anfrage zu verstehen.
  5. Was Sie erwartet und was Sie erhalten haben. Sie erwarteten Code 200 und Daten, bekamen einen Verbindungsfehler. Sie erwarteten das Laden der Seite, bekamen endloses Laden. Der Unterschied zwischen Erwartung und Realität ist der Kern des Problems.

⚠️ Achtung: Ersetzen Sie Konkretes nicht durch Emotionen. „Alles ist langsam und überhaupt schrecklich“ enthält keine technischen Informationen. „Die Antwort kommt in 40 Sekunden statt der üblichen 2“ enthält sie.

Wie man die Zeit richtig festhält

Wenn das Problem gerade jetzt auftritt, schauen Sie auf die Uhr und notieren Sie die Zeit sofort. Wenn es in der Vergangenheit lag, rekonstruieren Sie die Zeit anhand der Logs Ihrer Anwendung oder des Browserverlaufs. Je genauer der Zeitstempel, desto schneller wird der Eintrag auf der Serverseite gefunden.

✅ Prüfung: Sie haben fünf notierte Fakten. Lesen Sie sie laut vor. Wenn eine Person, die Ihren Bildschirm nicht sieht, versteht, was, wo und wann passiert ist, ist der minimale Datensatz gesammelt.

Schritt 2: Das Problem mit einem curl-Befehl reproduzieren

Ziel der Etappe: Das Problem auf einen einzigen Befehl reduzieren, den der Ingenieur gedanklich oder wörtlich wiederholen kann, und eine detaillierte technische Ausgabe erhalten.

Ein Browser und ein komplexes Skript führen Dutzende versteckte Aktionen aus. Es ist schwierig, das Problem darin zu isolieren. Das curl-Dienstprogramm führt genau eine Anfrage aus und zeigt jeden Schritt davon. Das ist das ideale Reproduktionswerkzeug.

Basibefehl über den Proxeon-Proxy

Stellen Sie den Befehl aus Ihren Daten zusammen. Die allgemeine Form ist:

curl -v -x http://ЛОГИН:ПАРОЛЬ@ХОСТ:ПОРТ https://ЦЕЛЕВОЙ-АДРЕС

Erläutern wir die Flags. -v aktiviert den ausführlichen Modus (verbose): curl zeigt den gesamten Verbindungsverlauf Zeile für Zeile. -x gibt den Proxy an, über den die Anfrage läuft. Danach folgt die Proxy-Adresse mit Authentifizierung. Am Ende die Zieladresse.

Beispiel mit eingesetzten Werten (Daten sind fiktiv):

curl -v -x http://user123:secretpass@proxy.proxeon.net:8080 https://api.example.com/v2/data

Zeitmessung und Dateiausgabe hinzufügen

Um die Ausgabe maximal informativ zu gestalten, erweitern wir den Befehl. Das Flag -w fügt am Ende eine Zusammenfassung der Timings hinzu.

curl -v -x http://user123:secretpass@proxy.proxeon.net:8080 -w "Итоговый код: %{http_code}, общее время: %{time_total}s" https://api.example.com/v2/data

Jetzt sehen Sie ganz am Ende der Ausgabe den endgültigen HTTP-Code und die Gesamtzeit der Anfrage. Das sind die Schlüsselzahlen für die Geschwindigkeitsdiagnose.

Tipp: Wenn das Problem in langsamer Arbeit und nicht in einem Fehler liegt, fügen Sie detaillierte Timings über 

-w "dns: %{time_namelookup} connect: %{time_connect} start: %{time_starttransfer} total: %{time_total}"
hinzu. Das zeigt, an welcher Etappe Zeit verloren geht.

Für SOCKS5-Proxys

Wenn Ihr Proxy vom Typ SOCKS5 ist, ändern Sie das Schema in der Adresse:

curl -v -x socks5://user123:secretpass@proxy.proxeon.net:1080 https://api.example.com/v2/data

⚠️ Achtung: Der Befehl enthält Ihr echtes Login und Passwort. Führen Sie ihn in Ihrem Terminal aus, aber kopieren Sie ihn NICHT mit den Geheimnissen in die E-Mail. In der Anfrage werden Login und Passwort durch Platzhalter ersetzt — dazu in Schritt 5.

Ausführungsreihenfolge

  1. Öffnen Sie das Terminal.
  2. Fügen Sie den zusammengestellten Befehl ein und ersetzen Sie die Werte durch Ihre echten Daten.
  3. Drücken Sie Enter und warten Sie auf den Abschluss.
  4. Markieren Sie die gesamte Ausgabe von der ersten bis zur letzten Zeile und kopieren Sie sie in eine Textdatei.

✅ Prüfung: Sie haben eine mehrzeilige Ausgabe erhalten, in der Zeilen sichtbar sind, die mit den Zeichen „*“, „>“ und „<“ beginnen. Wenn eine Ausgabe vorhanden ist, war die Reproduktion erfolgreich, auch wenn die Anfrage mit einem Fehler endete — auch der Fehler ist wertvolle Information.

Schritt 3: Die Ausgabe Zeile für Zeile lesen und die Problemgrenze finden

Ziel der Etappe: Lernen zu verstehen, was die curl-Ausgabe zeigt, und festzustellen, an welchem Glied die Anfrage gestoppt wurde. Die Entschlüsselung konkreter Fehlercodes duplizieren wir hier nicht — dafür gibt es einen separaten Artikel in der Proxeon-Wissensdatenbank, verlinken Sie ihn bei Bedarf in Ihrer Anfrage.

Drei Arten von Zeilen in der Ausgabe

Die ausführliche curl-Ausgabe verwendet Präfixe, an denen man sich leicht orientieren kann.

  • Zeilen mit Sternchen (*) — Dienstmeldungen von curl selbst über den Verbindungsverlauf: Namensauflösung, Verbindungsaufbau mit dem Proxy, Verschlüsselungs-Handshake. Das ist die interne Küche.
  • Zeilen mit Rechtspfeil (>) — das ist, was Ihr Client SENDET. Anfrage-Header, Methode, Pfad.
  • Zeilen mit Linkspfeil (<) — das ist, was Ihnen GEANTWORTET wird. Antwortcode, Server-Header.

Wo die Grenze Client — Proxy verläuft

Am Anfang der curl-Ausgabe meldet curl, dass es eine Verbindung mit dem Proxy herstellt. Sie sehen eine Zeile wie „Connected to proxy.proxeon.net port 8080“. Wenn diese Zeile fehlt und stattdessen ein Verbindungsfehler steht, hat die Anfrage den Proxy nicht erreicht. Das Problem liegt an der Grenze Client — Proxy: Vielleicht ist der Port geschlossen, die Adresse falsch oder ein lokaler Filter stört.

Wenn die Zeile über die Verbindung zum Proxy vorhanden ist, aber danach ein Authentifizierungsfehler folgt, ist der Proxy erreichbar, hat aber Ihr Login und Passwort nicht akzeptiert. Das ist ebenfalls die Grenze Client — Proxy, aber auf der Ebene der Authentifizierung.

Wo die Grenze Proxy — Server verläuft

Nach erfolgreicher Verbindung mit dem Proxy zeigt curl den Verbindungsaufbau mit dem Zielserver über den Proxy. Wenn hier ein Fehler auftritt, hat der Proxy die Anfrage angenommen, konnte das Ziel aber nicht erreichen. Das Problem liegt an der Grenze Proxy — Server: Die Zielwebsite ist nicht verfügbar, lehnt die Verbindung ab oder antwortet langsam.

Wenn Sie jedoch eine Antwortzeile mit Linkspfeil sehen, zum Beispiel „< HTTP/1.1 200“ oder einen anderen Code, hat die gesamte Kette funktioniert und Sie haben eine Antwort erhalten. Dann ist es eine Frage des Antwortinhalts, nicht der Proxy-Funktion.

Schlüsselzeilen, die für den Ingenieur wichtig sind

  1. Die Zeile der Verbindung zum Proxy — bestätigt, dass das erste Glied funktioniert.
  2. Die Zeile über die Authentifizierung am Proxy — zeigt, ob die Anmeldedaten akzeptiert wurden.
  3. Die Zeile über den Verschlüsselungs-Handshake (TLS) — wichtig für HTTPS-Ziele.
  4. Die erste Antwortzeile mit Linkspfeil — das endgültige Urteil der Kette.
  5. Die abschließende Zusammenfassung mit Code und Zeit aus dem Flag -w.

Tipp: Versuchen Sie nicht, selbst eine Diagnose anhand des Fehlercodes zu stellen, wenn Sie unsicher sind. Ihre Aufgabe ist es, die vollständige Ausgabe beizufügen. Der Proxeon-Ingenieur liest sie genauer. Eine vollständige Entschlüsselung der Codes finden Sie in einem separaten Artikel der Wissensdatenbank — verweisen Sie darauf, wenn Sie tiefer eintauchen möchten.

✅ Prüfung: Sie können mit dem Finger auf die Zeile zeigen, nach der die Anfrage abgebrochen ist, und sagen, an welcher Grenze das war — Client-Proxy oder Proxy-Server. Wenn ja, haben Sie diese Etappe gemeistert.

Schritt 4: Prüfungen vor der Anfrage durchführen

Ziel der Etappe: Durch Ausschlussverfahren den Kreis der Ursachen einengen, noch bevor Sie den Support kontaktieren. Jede Prüfung schließt eine ganze Klasse von Problemen aus.

Das Prinzip ist einfach: Ändern Sie jeweils einen Parameter und beobachten Sie, ob sich das Verhalten ändert. Das ist der klassische ingenieurmäßige Ansatz zur Fehlerisolierung.

Vier Schlüsselprüfungen

  1. Andere Zielwebsite. Wiederholen Sie dieselbe Anfrage über denselben Proxy, aber an eine andere Adresse. Nehmen Sie eine zuverlässig stabile öffentliche Website. Wenn der Proxy für diese funktioniert, aber nicht für Ihr Ziel, hängt das Problem mit der Zielwebsite oder deren Verhältnis zum Proxy zusammen, nicht mit dem Proxy selbst.
  2. Anderes Protokoll. Wenn Sie HTTP verwendet haben, versuchen Sie ein HTTPS-Ziel und umgekehrt. Manchmal zeigt sich das Problem nur bei einem Protokoll, und das ist ein wichtiges Signal.
  3. Anderer Proxy. Wenn Sie einen zweiten Proxeon-Proxy haben, wiederholen Sie die Anfrage über diesen. Wenn der zweite funktioniert und der erste nicht, liegt das Problem beim konkreten Proxy. Wenn sich beide gleich verhalten, ist das Problem systemischer.
  4. Direkte Verbindung. Führen Sie die Anfrage an das Ziel OHNE Proxy direkt aus. Entfernen Sie das Flag -x. Wenn die Website auch direkt nicht erreichbar ist, liegt das Problem überhaupt nicht am Proxy, sondern an der Zielwebsite oder Ihrem Netzwerk.

Befehl für die direkte Prüfung

curl -v https://api.example.com/v2/data

Derselbe Befehl, aber ohne den Proxy-Teil. Vergleichen Sie das Ergebnis mit der Anfrage über den Proxy.

Tabelle: Was jede Prüfung ausschließt

Unten steht, wie die Ergebnisse der Prüfungen zu interpretieren sind.

  • Andere Website funktioniert, Ihre nicht. Schließt einen Defekt des Proxys insgesamt aus. Weist auf die Besonderheit der Interaktion des konkreten Ziels mit dem Proxy hin.
  • Anderes Protokoll funktioniert, Ihr nicht. Schließt völlige Unerreichbarkeit aus. Lokalisiert das Problem auf der Ebene des konkreten Protokolls oder Ports.
  • Anderer Proxy funktioniert, Ihrer nicht. Schließt ein Problem auf Ihrer Seite und im Netzwerk aus. Weist auf den konkreten Proxy hin.
  • Direkte Verbindung funktioniert auch nicht. Schließt eine Schuld des Proxys aus. Das Problem liegt an der Zielwebsite oder Ihrem Netzwerk.
  • Direkt funktioniert, über Proxy nicht. Bestätigt, dass es genau an der Verbindung mit dem Proxy liegt, und das ist genau das, wobei der Support helfen kann.

Tipp: Die Ergebnisse dieser vier Prüfungen sind der wertvollste Teil der Anfrage. Sie sparen dem Ingenieur die halbe Arbeit, weil Sie bereits Überflüssiges ausgeschlossen haben. Listen Sie sie unbedingt in der E-Mail auf.

⚠️ Achtung: Verwenden Sie diese Proxys ausschließlich für legale Aufgaben: Testen Ihrer Dienste, Sammlung öffentlicher Daten im Rahmen der Regeln, Arbeit mit APIs. Die Prüfungen sind nicht für Handlungen gedacht, die gegen die Regeln von Websites oder die Gesetzgebung verstoßen.

✅ Prüfung: Sie haben Ergebnisse für alle vier Prüfungen und können mit einem Satz sagen, was sie zusammengenommen ausschließen. Zum Beispiel: „Direkte Verbindung und anderer Proxy funktionieren, also liegt es am konkreten Proxy PX-48213 bei der Anfrage an dieses Ziel.“

Schritt 5: Daten über Ihre Seite sammeln

Ziel der Etappe: Die Umgebung beschreiben, in der das Problem auftritt. Die Hälfte unklarer Fälle erklärt sich durch Besonderheiten des Clients oder des lokalen Netzwerks.

Was über die Umgebung anzugeben ist

  1. Betriebssystem und Version. Windows 11, macOS 15, Ubuntu 24.04. Die genaue Version hilft, die Bedingungen zu reproduzieren.
  2. Client und Version. Womit Sie mit dem Proxy arbeiten: Browser und Version, Name und Version des Parsers oder der Bibliothek, curl-Version. Verschiedene Clients verarbeiten Proxys unterschiedlich.
  3. Art der Proxy-Konfiguration. Im System konfiguriert, im Browser, im Code übergeben, in Umgebungsvariablen gesetzt. Das beeinflusst, wie der Proxy genau angewendet wird.
  4. Vorhandensein eines Unternehmens- oder lokalen Filters. Arbeiten Sie aus einem Unternehmensnetzwerk, gibt es einen Virenscanner mit Netzwerkfilter, ist eine lokale Firewall aktiv. Solche Filter können Verbindungen abfangen oder blockieren, noch bevor sie den Proxy erreichen.
  5. Art der Internetverbindung. Heimprovider, mobiles Internet, Arbeitsnetzwerk. Manchmal beeinflusst der Provider die Erreichbarkeit.

Wie man die Client-Version herausfindet

Für curl verwenden Sie den bereits bekannten Befehl 

curl --version
Für den Browser öffnen Sie den Abschnitt „Über das Programm“ im Menü. Für eine Bibliothek im Code sehen Sie deren Version in der Abhängigkeitsdatei Ihres Projekts nach.

Prüfung des Unternehmensfilters

Wenn Sie in einem Unternehmensnetzwerk sind und einen Filter vermuten, lässt sich das leicht prüfen. Führen Sie eine Anfrage direkt an den Proxy ohne Ziel aus und sehen Sie, ob eine Verbindung hergestellt wird. Wenn selbst die direkte Verbindung zum Proxy-Port nicht durchgeht, aus einem anderen Netzwerk aber schon, ist wahrscheinlich ein Unternehmensfilter für ausgehende Verbindungen vorhanden.

Tipp: Unternehmensnetzwerke erlauben oft nur die Ports 80 und 443. Wenn Ihr Proxy auf einem nicht standardmäßigen Port läuft, fragen Sie Ihren Netzwerkadministrator, ob dieser Port nach außen offen ist. Das ist eine häufige und leicht lösbare Ursache.

✅ Prüfung: Sie haben eine ausgefüllte Liste von fünf Punkten zur Umgebung. Der Ingenieur weiß nach dem Lesen, unter welchen Bedingungen das Problem zu reproduzieren ist.

Schritt 6: Die Diagnose mit einem Skript automatisieren

Ziel der Etappe: Alle technischen Informationen in einer Textdatei sammeln, ohne sie manuell umzuschreiben. Das Skript macht dasselbe, was Sie manuell getan haben, aber in einem Durchlauf.

Skript für macOS und Linux

Erstellen Sie die Datei diag.sh mit folgendem Inhalt. Ersetzen Sie die Variablenwerte durch Ihre eigenen.

#!/bin/bash
PROXY="http://ЛОГИН:ПАРОЛЬ@ХОСТ:ПОРТ"
TARGET="https://ЦЕЛЕВОЙ-АДРЕС"
ALT="https://СТАБИЛЬНЫЙ-САЙТ"
OUT="diag_result.txt"
echo "=== Дата и время ===" > $OUT
date >> $OUT
echo "=== Версия curl ===" >> $OUT
curl --version >> $OUT 2>&1
echo "=== Запрос через прокси к цели ===" >> $OUT
curl -v -x $PROXY -w "code:%{http_code} total:%{time_total}s" $TARGET >> $OUT 2>&1
echo "=== Запрос через прокси к альтернативному сайту ===" >> $OUT
curl -v -x $PROXY -w "code:%{http_code} total:%{time_total}s" $ALT >> $OUT 2>&1
echo "=== Прямой запрос к цели без прокси ===" >> $OUT
curl -v -w "code:%{http_code} total:%{time_total}s" $TARGET >> $OUT 2>&1
echo "Готово. Файл: $OUT"

Wie man das Skript ausführt

  1. Speichern Sie die Datei unter dem Namen diag.sh.
  2. Tragen Sie Ihre Werte in die Variablen PROXY, TARGET und ALT ein.
  3. Wechseln Sie im Terminal in den Ordner mit der Datei.
  4. Machen Sie die Datei mit dem Befehl 
    chmod +x diag.sh
    ausführbar.
  5. Starten Sie sie mit dem Befehl 
    ./diag.sh
  6. Öffnen Sie nach Abschluss die Datei diag_result.txt.

Skript für Windows (PowerShell)

Erstellen Sie die Datei diag.ps1 mit analoger Logik.

$Proxy = "http://ЛОГИН:ПАРОЛЬ@ХОСТ:ПОРТ"
$Target = "https://ЦЕЛЕВОЙ-АДРЕС"
$Alt = "https://СТАБИЛЬНЫЙ-САЙТ"
$Out = "diag_result.txt"
"=== Дата и время ===" | Out-File $Out
Get-Date | Out-File $Out -Append
"=== Версия curl ===" | Out-File $Out -Append
curl --version 2>&1 | Out-File $Out -Append
"=== Через прокси к цели ===" | Out-File $Out -Append
curl -v -x $Proxy -w "code:%{http_code} total:%{time_total}s" $Target 2>&1 | Out-File $Out -Append
"=== Через прокси к альтернативе ===" | Out-File $Out -Append
curl -v -x $Proxy $Alt 2>&1 | Out-File $Out -Append
"=== Прямой запрос ===" | Out-File $Out -Append
curl -v $Target 2>&1 | Out-File $Out -Append

Starten Sie es in PowerShell mit dem Befehl 

.\diag.ps1
und öffnen Sie die entstandene Datei.

⚠️ Achtung: Die Datei diag_result.txt enthält Ihr Login und Passwort im Klartext, weil sie in der Variable PROXY standen. Vor dem Versand an den Support MÜSSEN Sie sie gemäß der Anleitung aus Schritt 7 bereinigen.

Tipp: Bewahren Sie das Skript mit leeren Variablen auf und fügen Sie die Werte erst vor dem Start ein. So riskieren Sie nicht, versehentlich eine Datei mit Geheimnissen darin zu teilen.

✅ Prüfung: Die Datei diag_result.txt wurde erstellt und enthält mehrere Blöcke: die curl-Version, Anfragen über den Proxy an zwei Websites und eine direkte Anfrage. Das ist ein fertiges Paket technischer Diagnose.

Schritt 7: Logs vor dem Versand sicher bereinigen

Ziel der Etappe: Aus den gesammelten Daten alles Geheime entfernen und dabei ihren diagnostischen Wert bewahren. Logs mit Passwörtern dürfen auf keinen Fall versendet werden.

Was unbedingt herauszuschneiden ist

  • Das Proxy-Passwort. In der Ausgabe könnte es in die Verbindungszeile geraten sein. Finden und ersetzen.
  • Das Login, wenn es an Zahlungsdaten gebunden ist. Normalerweise kann das Login bleiben, aber wenn es Teil einer sensiblen Kombination ist, ersetzen Sie auch dieses.
  • Autorisierungs-Token. Wenn in den Anfrage-Headern Authorization, Bearer-Token, API-Schlüssel, Session-Cookies stehen — alles herausschneiden.
  • Personenbezogene Daten. Alle Namen, Adressen, Telefonnummern, falls sie versehentlich in den Anfrage- oder Antwortkörper geraten sind.

Wodurch ersetzen

Löschen Sie die Zeile nicht vollständig — so geht die Struktur verloren. Ersetzen Sie das Geheimnis durch einen verständlichen Platzhalter und behalten Sie nach Möglichkeit Länge und Format bei. Beispiele für Ersetzungen:

  • Passwort ersetzen durch [ПАРОЛЬ_СКРЫТ].
  • Login ersetzen durch [ЛОГИН_СКРЫТ].
  • Token ersetzen durch [ТОКЕН_СКРЫТ].

So sieht der Ingenieur, dass an dieser Stelle ein Token war, aber nicht dessen Wert. Die Struktur bleibt erhalten, die Sicherheit ebenfalls.

Reihenfolge der Bereinigung

  1. Öffnen Sie die Datei diag_result.txt in einem Texteditor.
  2. Verwenden Sie die Suche (Strg+F) nach Ihrem Passwort und ersetzen Sie alle Vorkommen durch den Platzhalter.
  3. Tun Sie dasselbe mit dem Login, wenn Sie ihn verbergen möchten.
  4. Sehen Sie die Zeilen mit den Headern Authorization, Cookie, api-key durch. Ersetzen Sie die Werte durch Platzhalter.
  5. Speichern Sie die Datei unter einem neuen Namen, zum Beispiel diag_clean.txt, um sie nicht mit dem Original zu verwechseln.

⚠️ Achtung: Prüfen Sie die Datei vor dem Versand zweimal. Das Passwort könnte nicht nur im Befehl, sondern auch in den curl-Ausgabezeilen vorkommen. Ein übersehenes Geheimnis ist ein Leck, das zur Kompromittierung Ihres Proxys führen kann.

Tipp: Bewahren Sie das Original diag_result.txt lokal auf und senden Sie nur die bereinigte Kopie. Wenn der Ingenieur eine Klärung erbittet, haben Sie die vollständigen Daten zur Hand.

✅ Prüfung: Öffnen Sie die bereinigte Datei und suchen Sie nach Ihrem Passwort. Null Treffer — die Bereinigung war erfolgreich. Die Ausgabestruktur ist dabei erhalten geblieben.

Schritt 8: Die fertige Anfragevorlage ausfüllen

Ziel der Etappe: Alles in einer E-Mail zusammenfassen, die der Ingenieur liest und sofort die Aufgabe versteht. Unten steht eine Vorlage zum Kopieren.

Vorlage für eine Anfrage an den Proxeon-Support

Тема: Проблема с прокси [ИДЕНТИФИКАТОР] при обращении к [ЦЕЛЬ]

1. Идентификатор прокси: [например PX-48213]
2. Тип прокси: [HTTP / HTTPS / SOCKS5]
3. Время проблемы: [12.03.2026, 14:32, UTC+3]
4. Целевой адрес: [https://api.example.com/v2/data]
5. Что делал: [отправлял GET-запрос из curl]
6. Ожидал: [код 200 и данные]
7. Получил: [ошибку соединения / медленный ответ / код ошибки]

Результаты проверок:
- Другой сайт через этот прокси: [работает / не работает]
- Прямое соединение без прокси: [работает / не работает]
- Другой прокси к той же цели: [работает / не работает / нет второго прокси]

Окружение:
- ОС: [Windows 11]
- Клиент: [curl 8.6.0]
- Настройка прокси: [флаг -x в curl]
- Корпоративный фильтр: [нет / есть, порты 80 и 443]

Вывод диагностики (логин и пароль скрыты) прилагаю в файле diag_clean.txt.

Краткий вывод: по моим проверкам проблема на границе [клиент-прокси / прокси-сервер], потому что [прямое соединение работает, а через прокси нет].

Wie man richtig ausfüllt

  1. Kopieren Sie die Vorlage in den E-Mail- oder Ticket-Text.
  2. Ersetzen Sie jedes Feld in eckigen Klammern durch Ihre Daten.
  3. Fügen Sie die bereinigte Datei diag_clean.txt bei.
  4. Lesen Sie die E-Mail vollständig durch: Ist sie für eine außenstehende Person verständlich?
  5. Senden Sie sie ab.

Tipp: Die Zeile „Kurzfazit“ am Ende ist die nützlichste. Darin formulieren Sie selbst eine Hypothese auf Basis der Prüfungen. Auch wenn die Hypothese ungenau ist, zeigt sie dem Ingenieur Ihren Gedankengang und spart Zeit.

✅ Prüfung: In der E-Mail ist kein einziges Feld in eckigen Klammern mehr — alle sind ausgefüllt. Die bereinigte Datei ist beigefügt. Es gibt ein kurzes Fazit mit Hypothese. Die Anfrage ist versandbereit.

Ergebniskontrolle: Checkliste für die Bereitschaft der Anfrage

Gehen Sie vor dem Versand eine kurze Checkliste durch. Sie garantiert, dass Sie nichts übersehen haben.

  • Die genaue Proxy-ID ist angegeben, nicht eine Beschreibung.
  • Es gibt die Uhrzeit des Ereignisses mit ausdrücklicher Zeitzone.
  • Die vollständige Zieladresse ist angegeben.
  • Es ist beschrieben, was Sie getan haben, was Sie erwartet und was Sie erhalten haben.
  • Die vollständige curl-Ausgabe im ausführlichen Modus ist beigefügt.
  • Mindestens zwei Ausschlussprüfungen wurden durchgeführt und beschrieben.
  • Betriebssystem, Client und Version sind angegeben.
  • Aus den Logs sind Passwort und alle Token entfernt.
  • Die Diagnosedatei ist beigefügt und verständlich benannt.
  • Es gibt ein kurzes Fazit mit Ihrer Hypothese.

Wenn alle Punkte abgehakt sind, gehört Ihre Anfrage zu denen, die mit der ersten Antwort gelöst werden. Der Ingenieur muss nichts klären — er hat das vollständige Bild.

✅ Prüfung: Alle zehn Punkte der Checkliste sind erfüllt. Das ist der Erfolgsindikator: Die Anfrage ist selbsttragend.

Typische Fehler und ihre Lösungen

Betrachten wir häufige Probleme bei der Diagnoseerhebung und ihre Behebung.

Problem 1: curl gibt sofort einen Fehler aus, ohne Verbindung zum Proxy

Ursache: falsches Format der Proxy-Adresse oder Tippfehler im Schema (http statt socks5 oder umgekehrt).

Lösung: Prüfen Sie den Proxy-Typ im Proxeon-Kundenbereich und setzen Sie das richtige Schema ein. Stellen Sie sicher, dass der Port korrekt angegeben und mit einem Doppelpunkt abgetrennt ist.

Problem 2: Authentifizierungsfehler am Proxy

Ursache: falsches Login oder Passwort, oder Sonderzeichen im Passwort sind nicht maskiert.

Lösung: Überprüfen Sie die Anmeldedaten. Wenn das Passwort die Zeichen @, :, / enthält, können diese die Zeile brechen. Übergeben Sie in diesem Fall die Authentifizierung mit dem separaten Flag 

--proxy-user ЛОГИН:ПАРОЛЬ
statt sie in die URL einzufügen.

Problem 3: Das Skript startet nicht in Windows

Ursache: Die PowerShell-Ausführungsrichtlinie blockiert lokale Skripte.

Lösung: Starten Sie PowerShell als Administrator und erlauben Sie die Ausführung für die aktuelle Sitzung mit dem Befehl zur Festlegung der RemoteSigned-Richtlinie auf Prozessebene. Nach dem Sammeln der Daten stellen Sie die ursprüngliche Richtlinie wieder her.

Problem 4: In der Ausgabe fehlen Details, nur die abschließende Zeile ist da

Ursache: Das Flag -v, das den ausführlichen Modus aktiviert, wurde vergessen.

Lösung: Fügen Sie -v direkt nach curl hinzu. Genau es zeigt den zeilenweisen Verbindungsverlauf, ohne den die Diagnose nutzlos ist.

Problem 5: Das Passwort ist versehentlich in der gesendeten Datei geblieben

Ursache: Die Bereinigung wurde unaufmerksam durchgeführt, das Passwort kam in einer Ausgabezeile vor, nicht nur im Befehl.

Lösung: Ändern Sie sofort das Proxy-Passwort im Proxeon-Kundenbereich. Führen Sie künftig immer eine Suche nach dem Passwort in der bereinigten Datei vor dem Versand durch.

Problem 6: Das Problem lässt sich in curl nicht reproduzieren, ist aber im Browser vorhanden

Ursache: Der Browser fügt Header, Cookies hinzu oder verwendet eine andere Art der Proxy-Konfiguration.

Lösung: Geben Sie in der Anfrage ehrlich an, dass das Problem in curl nicht auftritt, im Browser aber schon. Fügen Sie Name und Version des Browsers und die Art der Proxy-Konfiguration darin bei. Das ist an sich schon diagnostische Information.

Problem 7: Die Zeit in den Logs stimmt nicht mit Ihrer überein

Ursache: Sie haben die lokale Zeit ohne Zeitzone angegeben, der Server arbeitet aber in UTC.

Lösung: Geben Sie immer die Zone ausdrücklich an. Wenn Sie unsicher sind, fügen Sie beide Zeitstempel bei: Ihre lokale Zeit und ihr UTC-Äquivalent.

Zusätzliche Möglichkeiten: erweiterte Diagnose

Wenn der Basissatz nicht ausreicht, hier einige Werkzeuge für eine tiefere Analyse. Sie sind für fortgeschrittene Nutzer nützlich.

Detaillierte Timings für Geschwindigkeitsprobleme

Wenn der Proxy funktioniert, aber langsam ist, ist es wichtig zu verstehen, an welcher Etappe Zeit verloren geht. Das erweiterte Flag -w zeigt die Aufschlüsselung.

curl -o /dev/null -s -w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" -x http://ЛОГИН:ПАРОЛЬ@ХОСТ:ПОРТ https://ЦЕЛЬ

Diese Zahlen zeigen, wie viel Zeit für die Namensauflösung, den Verbindungsaufbau, die Verschlüsselung und den Empfang des ersten Bytes aufgewendet wurde. Wenn ttfb groß ist, liegt die Verzögerung auf der Zielseite. Wenn connect groß ist, liegt das Problem im Netzwerk bis zum Proxy.

Wiederholbarkeit des Problems

Wenn das Problem schwankend ist, sammeln Sie eine Serie von Anfragen und zeigen Sie, dass ein Teil durchgeht und ein Teil nicht. Eine einfache Schleife aus mehreren Anfragen mit Aufzeichnung der Antwortcodes liefert Statistiken. Stabilität oder deren Fehlen ist ein wichtiger Fakt für den Support.

Mehrere Ziele auf einmal prüfen

Erstellen Sie eine Liste aus drei bis vier Adressen und führen Sie sie in einer Serie durch den Proxy. So sehen Sie sofort, ob das Problem spezifisch für ein Ziel oder allgemein ist.

Tipp: Fügen Sie erweiterte Daten nur bei, wenn die Basisdiagnose nicht ausreichte. Ein Übermaß an Informationen ohne Struktur ist genauso schädlich wie deren Mangel. Beginnen Sie mit dem Minimum und vertiefen Sie auf Anfrage des Ingenieurs.

FAQ: häufige Fragen zur Diagnoseerhebung

Muss man unbedingt curl verwenden?

Nein, aber curl ist das universellste und für den Ingenieur verständlichste Werkzeug. Seine Ausgabe ist auf allen Systemen gleich. Wenn Sie über eine Bibliothek im Code arbeiten, fügen Sie auch deren Ausgabe bei, aber die curl-Prüfung ist als Referenz trotzdem wertvoll.

Was tun, wenn das Problem bereits vorüber ist und nicht wieder auftritt?

Halten Sie alles fest, woran Sie sich erinnern: ungefähre Zeit, Ziel, Art des Fehlers. Fügen Sie die Logs Ihrer Anwendung für diesen Zeitraum bei. Auch unvollständige Daten mit genauer Zeit helfen, den Eintrag auf dem Server zu finden.

Muss man Logs beifügen, wenn der Fehler aus der Beschreibung offensichtlich ist?

Ja. Was Ihnen offensichtlich erscheint, bedarf der Bestätigung durch Fakten. Logs nehmen Vermutungen weg und ermöglichen eine genaue Antwort statt einer Annahme.

Kann man Login und Passwort senden, damit der Support selbst alles prüft?

Nein. Geheimnisse werden nicht in der Korrespondenz übermittelt. Der Proxeon-Support hat Zugang zu Ihrem Konto über die ID ohne Passwort. Die ID reicht für die Prüfung auf der Serverseite aus.

Wie schnell kommt die Antwort, wenn alles richtig gesammelt wurde?

Eine vollständige Anfrage verkürzt die Zeit bis zur Lösung um ein Vielfaches, weil sie den Klärungszyklus beseitigt. Die genauen Fristen hängen von der Auslastung des Supports ab, aber Sie vermeiden sicher mehrere Runden Korrespondenz.

Was, wenn curl Erfolg zeigt, die Anwendung aber trotzdem nicht funktioniert?

Das ist ein wertvoller Fakt: Das Problem liegt nicht am Proxy als solchem, sondern daran, wie die Anwendung ihn verwendet. Geben Sie das in der Anfrage an, fügen Sie die Proxy-Einstellungen in der Anwendung und deren Version bei.

Muss man die Zieladresse angeben, wenn sie öffentlich ist?

Ja, unbedingt. Das Verhalten des Proxys kann vom konkreten Ziel abhängen. Ohne Adresse kann der Ingenieur genau Ihren Fall nicht reproduzieren.

Wie erkennt man, ob der Port richtig ist oder ein anderer benötigt wird?

Der Port ist in der Proxy-Karte im Kundenbereich angegeben. Verschiedene Proxy-Typen verwenden verschiedene Ports. Vergleichen Sie mit dem Kundenbereich und setzen Sie den Port nicht aufs Geratewohl ein.

Kann man die Bereinigung der Logs von Geheimnissen automatisieren?

Über den Autor

Roman Melnikov

Roman Melnikov

Technical Writer and System Administrator

Berufserfahrung: Technical writer and DevOps engineer with 9 years of experience. Created over 50 detailed guides on system configuration and administration. His instructions helped thousands of professionals successfully solve technical tasks. Popular author on Habr and YouTube.
Ausbildung: Bauman Moscow State Technical University. Information Systems and Technologies
Expertise:
Technical Documentation DevOps System Administration Linux Docker and Kubernetes CI/CD Infrastructure Automation Cloud Technologies System Monitoring Bash and Python Scripting

Diesen Artikel teilen: