Unsere Position, die wir gleich zu Beginn klarstellen möchten: Wir sind Geonode und verkaufen Proxys, daher erhalten wir viele Meldungen wie „Mein Proxy funktioniert nicht“. Ganz ehrlich gesagt ist der Port so gut wie nie das Problem. Nach unserer Erfahrung sieht die Reihenfolge der Wahrscheinlichkeiten so aus: falsche Anmeldedaten, eine IP-Whitelist, die du vergessen hast zu aktualisieren, die Verwendung des einfachen HTTP-Ports für eine HTTPS-Anfrage, die Blockierung durch das Ziel und erst dann eine tatsächlich falsche Portnummer. Wenn du ein Problem beheben möchtest, arbeite diese Liste der Reihe nach ab, anstatt wahllos Portnummern auszuprobieren – der letzte Ansatz fühlt sich produktiv an, ist es aber fast nie.
Allerdings macht das Verständnis der Funktion der Portnummer die gesamte Fehlerklassifizierung verständlich.
Was ein Port eigentlich ist
Ein Rechner hat eine Adresse und viele Programme, die möglicherweise Netzwerkverkehr benötigen. Anhand der Portnummer erkennt das Betriebssystem, zu welchem Programm eine bestimmte Verbindung gehört.
Die Adresse leitet das Paket an den Rechner weiter. Der Port leitet es an den richtigen Prozess auf diesem Rechner weiter. Ein einzelner Server kann gleichzeitig einen Webserver auf Port 443, einen SSH-Daemon auf Port 22 und einen Proxy auf Port 8080 betreiben, da jede Verbindung einen Zielport enthält, der sie an den richtigen Listener weiterleitet.
Speziell bei einem Proxy hat der Port eine zusätzliche Funktion: Ein einzelner Proxy-Server hört häufig auf mehreren Ports, die jeweils unterschiedlich konfiguriert sind. Gleiche Software, derselbe Rechner, unterschiedliches Verhalten, je nachdem, mit welcher Nummer man sich verbindet. Deshalb stellt dir dein Provider eine Liste statt eines einzelnen Werts zur Verfügung – ein Punkt, auf den wir noch zurückkommen werden.
Die drei Portbereiche
Ports reichen von 0 bis 65535, und RFC 6335 unterteilt diesen Bereich in drei Bereiche:
| Bereich | Name | Nummern | Zuweisung |
|---|
| System | Bekannte Ports | 0–1023 | Von der IANA zugewiesen |
| Benutzer | Registrierte Ports | 1024–49151 | Von der IANA zugewiesen |
| Dynamisch | Private oder kurzlebige Ports | 49152–65535 | Werden nie zugewiesen |
In der Praxis haben zwei Konsequenzen Bedeutung.
Für die Bindung an Systemports sind in der Regel erweiterte Berechtigungen erforderlich. Auf Unix-ähnlichen Systemen erfordert das Binden eines Ports unter 1024 traditionell Root-Rechte. Dies ist der direkte Grund, warum Proxys üblicherweise auf Port 8080 oder 3128 statt auf Port 80 laufen – einen Proxy als Root auszuführen, um einen niedrigen Port zu beanspruchen, ist ein schlechter Tausch für einen rein kosmetischen Vorteil.
Dynamische Ports sind der Ursprung Ihrer eigenen Verbindungen. Wenn Sie eine Verbindung zu einem Proxy auf Port 8080 herstellen, wählt Ihr Rechner einen temporären Quellport aus dem oberen Bereich aus. Dies bleibt unsichtbar, bis Sie ein Firewall-Protokoll lesen und sich fragen, warum Ihr Datenverkehr scheinbar von Port 51423 stammt.
Die gängigen Proxy-Ports und was die IANA tatsächlich sagt
An dieser Stelle weichen die gängige Meinung und die offiziellen Angaben voneinander ab, und diese Abweichung ist aufschlussreich. Diese Einträge stammen aus dem IANA-Register für Dienstnamen und Transportprotokoll-Portnummern und wurden direkt aus der veröffentlichten CSV-Datei entnommen.
| Port | Wie er im Volksmund genannt wird | Was die IANA tatsächlich registriert |
|---|
| 8080 | Der Standard-Proxy-Port | http-alt — „HTTP Alternate (siehe Port 80)“ |
| 3128 | Der Squid-Port | ndl-aas — „Active API Server Port“ |
| 1080 | SOCKS | socks — „Socks“ |
| 8118 | Privoxy | privoxy — „Privoxy HTTP-Proxy“ |
| 8888 | Alternativer Proxy-Port | ddi-tcp-1 — „NewsEDGE-Server TCP (TCP 1)“ |
| 9050 | Tor SOCKS | versiera — „Versiera Agent Listener“ |
| 8081 | Sekundärer Proxy-Port | sunproxyadmin — „Sun Proxy Admin Service“ |
Lesen Sie diese Tabelle noch einmal durch, denn sie widerlegt eine weit verbreitete Annahme. Von den Ports, die allgemein als „Proxy-Ports“ gelten, sind nur 1080 und 8118 für irgendetwas Proxy-bezogenes registriert.
Port 3128 – allgemein als Squid-Standard bezeichnet, und er ist tatsächlich der Standard von Squid – ist für etwas registriert, das damit überhaupt nichts zu tun hat. Port 8888, der überall von Proxy-Tools verwendet wird, gehört zu einem Nachrichtenprodukt. Port 9050, den jeder Tor-Nutzer kennt, ist für einen Überwachungsagenten registriert.
Die Lehre daraus ist nicht, dass diese Tools etwas falsch machen. Die Registrierungsstelle erfasst beantragte Zuweisungen, und ein Großteil der weit verbreiteten Software hat sich einfach eine passende Nummer ausgesucht, die sich eher durch die Nutzung als durch die Registrierung zur Konvention entwickelt hat. Konvention und Registrierung sind unterschiedliche Systeme, und wenn sie miteinander in Konflikt stehen, folgt Ihre Software der Konvention.
Die praktische Erkenntnis: Die Portnummer sagt nichts Verbindliches darüber aus, was auf diesem Port lauscht. Ein Proxy kann auf jedem beliebigen Port laufen. Die konventionellen Nummern existieren, weil jemand einen Standard festlegen musste, nicht weil die Nummer eine Bedeutung hat.
Der Port bestimmt nicht das Protokoll
Der mit Abstand häufigste konzeptionelle Fehler in diesem Bereich.
Eine Verbindung zu Port 1080 macht Ihre Verbindung noch lange nicht zu einer SOCKS-Verbindung. Eine Verbindung zu Port 8080 bedeutet nicht, dass es sich um HTTP handelt. Der Port bestimmt, welcher Listener Ihre Verbindung empfängt; das Protokoll ist dasjenige, das dieser Listener unterstützt. Wenn diese beiden Angaben nicht übereinstimmen, schlägt die Verbindung auf eine Weise fehl, die oft verwirrend ist – Sie erhalten eine Zeitüberschreitung, einen Verbindungsabbruch oder eine Flut unlesbarer Bytes, anstatt einer hilfreichen Fehlermeldung.
Wenn Ihr Provider Ihnen also einen Endpunkt angibt, benötigen Sie drei Informationen, wobei der Port nur eine davon ist:
- Den Host
- Den Port
- Das Protokoll, das dieser Port unterstützt – HTTP, HTTPS, SOCKS4 oder SOCKS5
Die Client-Konfiguration muss das Protokoll explizit angeben. In curl wird dies über das Schema im Argument -x übermittelt:
curl -x http://proxy.example.com:8080 https://example.com
curl -x socks5://proxy.example.com:1080 https://example.com
curl -x socks5h://proxy.example.com:1080 https://example.com
Diese dritte Form ist wichtiger als der Unterschied zwischen den ersten beiden. socks5h weist curl an, den Hostnamen zur Auflösung an den Proxy zu senden; bei der einfachen Form socks5 erfolgt die Auflösung lokal und die Adresse wird gesendet. Die Folge ist ein DNS-Leck: Ihr Datenverkehr wird über den Proxy geleitet, während Ihre DNS-Abfragen an Ihren eigenen Resolver gehen – genau diese Art von Inkonsistenz führt dazu, dass eine Sitzung markiert wird. Wenn Sie SOCKS5 für Zwecke nutzen, bei denen es darauf ankommt, den Anschein zu erwecken, sich an einem anderen Ort zu befinden, verwenden Sie socks5h.
Wie sich derselbe Port bei HTTP, HTTPS und SOCKS verhält
Die drei Fälle unterscheiden sich in Punkten, die die meisten verwirrenden Symptome erklären.
Einfaches HTTP über einen HTTP-Proxy. Ihr Client sendet die vollständige URL in der Anforderungszeile, und der Proxy ruft sie in Ihrem Namen ab. Der Proxy sieht alles und kann alles ändern.
HTTPS über einen HTTP-Proxy. Ihr Client sendet eine Anfrage an CONNECT, und sofern der Proxy dies zulässt, öffnet er einen TCP-Tunnel und leitet die Daten weiter, ohne sie lesen zu können. Aus diesem Grund verarbeitet ein HTTP-Proxy überhaupt HTTPS-Datenverkehr, und aus diesem Grund bedient derselbe Port beide Protokolle.
Daraus ergeben sich direkt zwei Fehlerfälle. Manche Proxys beschränken „CONNECT“ auf bestimmte Zielports – typischerweise 443 –, sodass eine HTTPS-Anfrage an einen nicht standardmäßigen Port abgelehnt wird, während das normale Surfen funktioniert. Und manche Ports sind nur für reines HTTP konfiguriert, wobei „CONNECT“ vollständig deaktiviert ist; das Symptom ist, dass HTTP-Anfragen funktionieren und HTTPS-Anfragen fehlschlagen, was wie ein Zertifikatsproblem aussieht, aber keines ist.
SOCKS. RFC 1928 definiert „SOCKS5“ als ein Protokoll, das unterhalb der Anwendungsschicht arbeitet. Es versteht HTTP überhaupt nicht – es leitet TCP-Verbindungen weiter, was es allgemeiner macht als einen HTTP-Proxy. Es funktioniert für Protokolle, die ein HTTP-Proxy nicht verarbeiten kann, und es kann keine HTTP-spezifischen Aufgaben wie Caching oder das Umschreiben von Headern ausführen.
Wenn Sie sich entscheiden müssen: Wählen Sie HTTP-Proxys für Web-Datenverkehr, bei dem Sie möglicherweise die Bearbeitung von Headern benötigen; wählen Sie „SOCKS5“, wenn Sie etwas proxen müssen, das kein HTTP ist, oder wenn der Proxy so wenig wie möglich wissen soll.
Warum Anbieter Ihnen mehrere Ports zur Verfügung stellen
Endpunkte mit mehreren Ports verwirren Neulinge, doch die Logik dahinter ist einfach: Der Anbieter kodiert die Konfiguration in der Portnummer, sodass Sie diese nicht auf andere Weise übermitteln müssen.
Gängige Schemata:
Rotationsverhalten. Ein Port liefert bei jeder Anfrage eine neue Ausgangsadresse; ein anderer behält dieselbe Adresse für eine Sitzung von einigen Minuten bei. Gleiche Anmeldedaten, gleicher Host, unterschiedlicher Port.
Geografische Ausrichtung. Ein Portblock ist bestimmten Ländern oder Regionen zugeordnet.
Sitzungsidentität. Ein Portbereich, in dem jede Nummer einer dauerhaften Sitzung entspricht, sodass man bei wiederholter Verbindung mit demselben Port immer dieselbe Ausgangsadresse erhält.
Protokoll. Ein Port unterstützt HTTP, ein anderer SOCKS5.
Einige Anbieter erreichen dasselbe stattdessen über die Benutzernamenssyntax – indem sie Parameter an den Benutzernamen anhängen, anstatt den Port zu variieren. Beide Ansätze existieren und keiner ist besser; Sie müssen einfach die Dokumentation des von Ihnen erworbenen Dienstes lesen, denn das Risiko beim Raten besteht darin, dass eine Anfrage zwar erfolgreich ist, aber etwas anderes bewirkt als beabsichtigt.
Dieser letzte Punkt ist besonders hervorzuheben. Ein falscher Port in einem Rotationsschema führt in der Regel nicht zu einem Fehler. Er führt zu einer funktionierenden Anfrage mit dem falschen Verhalten – einer ungewollten Sitzungspermanenz oder einem Land, das Sie nicht angefordert haben. Dies ist die Klasse der „stillen Fehler“, über die wir in Warum das Testen von Proxys wichtig ist geschrieben haben, und Verwechslungen bei den Ports sind eine der häufigsten Ursachen dafür.
Fehlerbehebung: Was die einzelnen Fehlermeldungen aussagen
Verschiedene Fehler deuten auf unterschiedliche Ursachen hin, und wenn man sie richtig interpretiert, erspart man sich viel Rätselraten.
| Symptom | Mögliche Ursache | Überprüfung |
|---|
| Verbindung sofort abgelehnt | An diesem Port hört nichts | Portnummer, Host |
| Timeout, keine Antwort | Firewall verwirft Pakete stillschweigend | Ausgehende Regeln, Status des Anbieters |
| 407 Proxy-Authentifizierung erforderlich | Anmeldedaten falsch oder fehlen | Benutzername, Passwort, IP-Whitelist |
| 403 vom Proxy selbst | Authentifiziert, aber nicht zugelassen | Tarifbeschränkungen, Zielbeschränkungen |
| HTTP funktioniert, HTTPS nicht | „CONNECT | |
“ an diesem Port deaktiviert oder eingeschränkt | Protokollport, Dokumentation des Anbieters |
| Müllbytes oder Protokollfehler | Protokollkonflikt | Ist dieser Port HTTP oder SOCKS? |
| Funktioniert, aber falsches Land oder falsche Sitzung | Falscher Port in einem Multi-Port-Schema | Portzuordnung des Anbieters |
Der Unterschied zwischen „Verbindung abgelehnt“ und „Timeout“ ist der nützlichste und wird am häufigsten übersehen. „Verbindung abgelehnt“ bedeutet, dass eine Antwort erfolgte und abgelehnt wurde – der Rechner ist erreichbar, aber an diesem Port lauscht nichts. „Zeitüberschreitung“ bedeutet, dass überhaupt keine Antwort erfolgte – in der Regel blockiert eine Firewall Pakete, entweder auf Ihrer Seite oder zwischen Ihnen und dem Proxy. Im ersten Fall deutet dies auf eine falsche Portnummer hin; im zweiten Fall ist dies so gut wie nie der Fall.
Ein schneller Isolationstest:
nc -zv proxy.example.com 8080
Wenn die Verbindung zustande kommt, ist der Port offen und erreichbar, und etwaige verbleibende Fehler liegen eher an der Authentifizierung oder am Protokoll als am Netzwerk. Wenn dies nicht der Fall ist, hören Sie auf, Ihre Anwendung zu debuggen – das Problem liegt darunter.
Und der Fall 407 verdient besondere Erwähnung, da er am häufigsten auftritt und für Personen, die ihn noch nicht kennen, wie ein Port-Problem aussieht. Das ist es jedoch nicht. Es bedeutet, dass Sie den Proxy erfolgreich erreicht haben und dieser Anmeldedaten verlangt, die Sie nicht oder falsch angegeben haben. Der Port war korrekt.
Ports, die Sie nicht freigeben sollten
Dies ist relevant, wenn Sie einen eigenen Proxy betreiben, anstatt einen zu kaufen.
Stellen Sie niemals einen nicht authentifizierten Proxy im Internet bereit. Ein offener Proxy wird innerhalb weniger Stunden entdeckt – der gesamte Adressraum wird kontinuierlich gescannt – und wird dazu genutzt, Datenverkehr weiterzuleiten, den Sie nicht autorisiert haben und der Ihrer Adresse zugeordnet wird. Die Folgen reichen davon, dass Ihre Adresse auf Sperrlisten landet, bis hin zu erheblich schlimmeren Konsequenzen. Wenn ein Proxy über das Internet erreichbar ist, muss er authentifiziert werden.
Schränken Sie den Zugriff nach Quelladresse ein, wo immer dies möglich ist. Eine IP-Whitelist in Verbindung mit Anmeldedaten ist eine sinnvolle Verbesserung gegenüber reinen Anmeldedaten und kostet nichts.
Gehen Sie nicht davon aus, dass ein ungewöhnlicher Port Schutz bietet. Die Verlagerung eines Dienstes auf Port 47281 macht ihn nicht unsichtbar. Das Scannen des gesamten Portbereichs eines einzelnen Hosts dauert nur Sekunden. Unauffälligkeit bringt Ihnen hier keinen messbaren Vorteil.
Schränken Sie die „CONNECT“-Ziele ein. Ein Proxy, der „CONNECT“ an jeden beliebigen Port auf jedem beliebigen Host weiterleitet, ist ein Allzweck-Relay. Die Beschränkung auf Port 443 und auf die Ziele, die Sie tatsächlich benötigen, reduziert erheblich die Möglichkeiten des Missbrauchs, falls Zugangsdaten offengelegt werden.
Binden Sie den Proxy an „localhost“, wenn Sie nur lokale Verbindungen benötigen. Ein Proxy, der ausschließlich von Software auf demselben Rechner genutzt wird, sollte auf 127.0.0.1 lauschen, nicht auf 0.0.0.0. Diese eine Zeile in der Konfiguration verhindert eine ganze Kategorie von Problemen und ist der häufigste Fehler bei selbst gehosteten Setups.
Häufig gestellte Fragen
Was ist der Standard-Proxy-Port?
Es gibt keinen allgemeingültigen Standard. 8080 ist die gängigste Konvention für HTTP-Proxys, 3128 für Squid-Installationen und 1080 für SOCKS. Keiner dieser Werte ist vorgeschrieben – ein Proxy kann auf jedem beliebigen Port lauschen – und in der IANA-Registrierung sind 8080 oder 3128 nicht einmal als Proxy-Dienste verzeichnet. Verwenden Sie immer den von Ihrem Anbieter angegebenen Port.
Ist 8080 ein Proxy-Port?
Nach Konvention häufig. Offiziell registriert die IANA 8080 als „http-alt“, beschrieben als „HTTP Alternate (siehe Port 80)“ – ein alternativer Webserver-Port, kein Proxy-Port. Er wurde zur Proxy-Konvention, weil er einprägsam ist und keine Root-Rechte für die Portzuweisung erfordert, nicht weil er eine besondere Bedeutung für Proxys hat.
Welchen Port verwendet „SOCKS5“?
Gemäß Konvention ist es Port 1080, und dies ist einer der wenigen Fälle, in denen die Konvention mit der Registrierung übereinstimmt: Die IANA listet 1080 als „socks“ auf. Einzelne Implementierungen variieren – der SOCKS-Port von Tor ist standardmäßig auf 9050 eingestellt, den die IANA für etwas völlig anderes registriert hat.
Warum funktioniert mein Proxy für HTTP, aber nicht für HTTPS?
Fast immer liegt es daran, dass dieser Port die Methode „CONNECT“ nicht zulässt – so wird HTTPS-Datenverkehr durch einen HTTP-Proxy getunnelt – oder daran, dass „CONNECT“ auf bestimmte Zielports beschränkt ist. Prüfen Sie, ob Ihr Anbieter einen separaten Port für HTTPS anbietet, und vergewissern Sie sich, dass der Zielport, mit dem Sie sich verbinden, zugelassen ist.
Wie finde ich heraus, welchen Proxy-Port ich verwenden muss?
In der Dokumentation Ihres Anbieters. Es gibt keine Möglichkeit, dies durch Überprüfung zuverlässig festzustellen, da die Portnummer keine aussagekräftigen Informationen darüber liefert, was auf diesem Port lauscht. Wenn Sie es dennoch überprüfen möchten, zeigt Ihnen nc -zv host port an, ob etwas auf dem Port lauscht, jedoch nicht, welches Protokoll verwendet wird.
Was ist der Unterschied zwischen einem Proxy-Port und einem Proxy-Server?
Der Server ist die Software und der Rechner, der Ihren Datenverkehr verarbeitet. Der Port ist einer der nummerierten Zugangspunkte dieses Rechners, mit dem Sie eine Verbindung herstellen. Ein Server hört häufig auf mehreren Ports mit unterschiedlichen Konfigurationen – unterschiedliches Rotationsverhalten, unterschiedliche Länder, unterschiedliche Protokolle –, weshalb Anbieter dir eine Liste statt einer einzigen Nummer zur Verfügung stellen.
Kann ich jeden beliebigen Port für einen Proxy verwenden?
Technisch gesehen ja, überall im Bereich von 1024 bis 65535 ohne besondere Berechtigungen. In der Praxis verwenden Sie jedoch die Ports, die Ihr Anbieter zuweist, da diese mit den Konfigurationen auf dessen Seite verknüpft sind. Wenn Sie einen eigenen Proxy betreiben, vermeiden Sie den dynamischen Bereich oberhalb von 49152, da Ihr Betriebssystem ab dort temporäre Quellports zuweist und Kollisionen zu zeitweiligen Problemen führen, deren Diagnose äußerst mühsam ist.
Hat die Portnummer Einfluss auf die Proxy-Geschwindigkeit?
Nein. Der Port ist ein Adressierungsdetail ohne eigene Leistungseigenschaften. Wenn verschiedene Ports desselben Anbieters unterschiedliche Leistungen erbringen, liegt das daran, dass sie über unterschiedliche Infrastrukturen geleitet werden oder unterschiedliche Rotationsverhalten aufweisen, nicht an der Nummer selbst.
Fazit
Der Proxy-Port ist ein Routing-Detail: Er teilt dem Zielrechner mit, welcher Prozess Ihre Verbindung bearbeiten soll – mehr nicht. Die Nummer selbst hat keine verbindliche Bedeutung, was die IANA-Registrierung deutlich zeigt – 3128 ist nicht für Squid registriert, 8888 gehört zu einem News-Produkt und 9050 ist ein Überwachungsagent. Dies sind durch die Nutzung etablierte Konventionen, und Konventionen sind das, woran sich Ihre Software orientiert.
Was das bedeutet, wenn etwas nicht funktioniert: Analysieren Sie die Fehlermeldung, anstatt über Portnummern zu spekulieren. „Connection refused“ deutet auf einen falschen Port hin. Ein Timeout deutet auf eine Firewall hin. Ein 407 bedeutet, dass der Port richtig war, Ihre Anmeldedaten jedoch nicht. Protokollfehler bedeuten, dass Sie eine Verbindung zu einem SOCKS-Listener hergestellt haben, der HTTP erwartet, oder umgekehrt. Jedes Symptom weist auf eine andere Ebene hin, und das Austauschen von Portnummern hilft nur im ersten Fall.
Und wenn Ihnen mehrere Ports für einen Endpunkt angegeben werden, lesen Sie die Dokumentation, anstatt einfach einen auszuwählen. Der Fehlermodus in diesem Fall ist keine Fehlermeldung – es handelt sich um eine Anfrage, die zwar funktioniert, dabei aber unbemerkt das falsche Land oder das falsche Sitzungsverhalten verwendet, was eine weitaus kostspieligere Art von Fehler darstellt.
