FlareSolverr funktioniert nicht? Jede Fehlermeldung, ihre Ursache und die Lösung

Wenn FlareSolverr kaputt scheint, lesen Sie zuerst, welches Programm den Fehler geschrieben hat, denn manche Meldungen schreibt FlareSolverr und andere schreiben Jackett und Prowlarr über es. Das Projekt selbst lebt: Version 3.5.2 erschien am 12. September 2026. Die meisten Fehler haben eine von drei Ursachen. Die Seite sperrt die Adresse, FlareSolverr und Ihre App erreichen die Seite von zwei verschiedenen Adressen aus, oder Ihre App erreicht FlareSolverr gar nicht.

Jede Meldung unten haben wir bis zu der Codezeile verfolgt, die sie ausgibt, in FlareSolverr 3.5.2, in FlareSolverrSharp 4.0.0 (der Bibliothek in Jackett) und in Prowlarr. Außerdem haben wir die 105 Issues, die im Jahr bis zum 25. September 2026 im Tracker von FlareSolverr eröffnet wurden, nach der Meldung sortiert, die jedes zitiert.

Ist FlareSolverr gerade kaputt?

Wahrscheinlich nicht für alle, denn das Projekt hat in den letzten zwölf Monaten sieben Versionen veröffentlicht, und die neueste, 3.5.2, stammt vom 12. September 2026. Manche Ratgeber sagen noch etwas anderes: Die Seite der TRaSH Guides zu Prowlarr, zuletzt im Oktober 2025 aktualisiert, nennt FlareSolverr „derzeit nicht funktionsfähig“ und verweist auf Issue #1253. Dieses Issue wurde am 3. Juni 2025 geschlossen, an dem Tag, an dem Version 3.3.22 änderte, wie FlareSolverr das Häkchen setzt.

Eine einzelne Seite kann trotzdem für alle brechen, wenn Cloudflare seine Seite ändert. Bevor Sie Ihr Setup ändern, machen Sie zwei Prüfungen.

• Öffnen Sie http://<host>:8191/ im Browser. FlareSolverr sollte mit FlareSolverr is ready! antworten, mit seiner Version und seinem User-Agent.
• Machen Sie den Test aus dem Wiki von FlareSolverr. Fügen Sie die öffentlichen Indexer 0Magnet, BT.etree und Torrent[CORE] hinzu, suchen Sie und beobachten Sie, wie jede Anfrage im Log von FlareSolverr erscheint.

Wenn beides funktioniert und eine Seite scheitert, liegt das Problem bei dieser Seite oder Ihrer Adresse. Suchen Sie auch in den offenen Issues nach dem Namen der Seite. In unserer Zählung wurden 41 der 105 Issues als Duplikate eines früheren Berichts geschlossen.

Keine Challenge erkannt, und der Status, der immer 200 sagt

Die Meldung Challenge not detected! gehört zu einer erfolgreichen Antwort. FlareSolverr hat die Seite geöffnet, nichts gefunden, was es als Challenge kennt, und die Seite mit ihren Cookies und dem Status ok zurückgeschickt. Eine Challenge erkennt es an zwei Seitentiteln, Just a moment... und DDoS-Guard, oder an zehn Seitenelementen. Alles andere zählt als keine Challenge.

Drei verschiedene Situationen führen dazu.

• Die Seite stellt dieser Adresse keine Challenge: Die Seite ist in Ordnung, und FlareSolverr hatte nichts zu tun. Ihre App kann von ihrer eigenen Adresse aus trotzdem eine Challenge bekommen, und das ist das Problem der Übergabe weiter unten.
• Die Challenge kam in einer anderen Sprache: Die Prüfung des Titels läuft auf Englisch. Zweimal im August und September 2026 gab der Triager des Projekts dieselbe Antwort: LANG=en_US setzen. FlareSolverr gibt das als Seitensprache an Chrome weiter.
• Der Browser hat die Seite nie erreicht: Manche Netzfehler kommen als normale Antwort zurück.

Der letzte Fall täuscht wegen des Status. In Version 3.5.2 ist der status in der Antwort immer 200, und die headers sind immer leer. Der Code setzt beides von Hand, weil Selenium sie nicht meldet. Ein Nutzer meldete einen Proxy-Fehler, der als ok und 200 zurückkam, mit der Chrome-Seite „This site can't be reached“ als HTML (Issue #1582). Andere Netzfehler lösen tatsächlich einen Fehler aus, mit einem Chrome-Code wie net::ERR_NAME_NOT_RESOLVED im Text.

Schauen Sie sich deshalb an, was FlareSolverr tatsächlich bekommen hat, und lassen Sie die 200 beiseite. Setzen Sie LOG_LEVEL=debug und LOG_HTML=true, um das HTML im Log auszugeben. Oder fügen Sie einer Anfrage "returnScreenshot": true hinzu, dann enthält die Antwort ein Bild der letzten Seite.

Zeitüberschreitung beim Lösen der Challenge

Die Meldung Error solving the challenge. Timeout after 60.0 seconds. heißt: Die Challenge war noch auf dem Bildschirm, als die Zeit ablief. Die Zahl ist Ihr maxTimeout in Sekunden, standardmäßig 60. Nutzer von Jackett sehen 55.0, weil Jackett standardmäßig 55.000 Millisekunden wartet. FlareSolverr setzt Error: vor die Zeile, und Jackett verpackt sie in einen eigenen Text, der mit FlareSolverr was unable to process the request beginnt.

Während es wartet, prüft FlareSolverr die Seite immer wieder und drückt in jeder Runde Tab und Leertaste, um das Häkchen zu setzen. Im Debug-Log gibt jede Runde The Cloudflare 'Verify you are human' button not found on the page. aus. Diese Zeile sieht nach der Ursache aus, erscheint aber in jeder Runde, und 10 der 105 Issues in unserer Zählung zitieren sie.

Gehen Sie die Ursachen in dieser Reihenfolge durch.

1. Geben Sie mehr Zeit: Die übliche Antwort des Triagers im Projekt ist eine Zeitgrenze von 120 Sekunden in Jackett oder Prowlarr. Prowlarr nimmt 1 bis 180 Sekunden an.
2. Geben Sie jeder Prüfung auf einem langsamen Rechner mehr Zeit: Seit 3.5.2 legt BROWSER_WAIT_TIMEOUT fest, wie viele Sekunden jede Prüfung wartet. Standard ist 1, was ein kleines NAS oder ein ausgelasteter Host verpassen kann.
3. Lassen Sie weniger Browser laufen: Jede Anfrage ohne Sitzung startet einen neuen Browser. Die README warnt vor vielen gleichzeitigen Anfragen auf einem Rechner mit wenig Speicher, und Jackett schickt FlareSolverr ohnehin eine Anfrage nach der anderen.
4. Aktualisieren Sie: Eine Lösung für eine geänderte Cloudflare-Seite kommt als neue Version.
5. Erkennen Sie, wann die Zeit nicht die Ursache ist: Cloudflare sagt, eine Managed Challenge könne mehr verlangen, wenn der Browser automatisiert wirkt. 2026 sagte der Triager außerdem mehreren Meldenden, dass die Seite höchstwahrscheinlich ihre Adresse sperre. Mehr Zeit behebt das nicht, und auch keine andere Einstellung auf dieser Seite.

Jackett meldet ungültige Cookies

Nur Jackett schreibt The cookies provided by FlareSolverr are not valid. Prowlarr hat keine solche Zeile, und seine eigene Fassung kommt weiter unten. Die Meldung bedeutet, dass die Übergabe gescheitert ist. Jackett hat bei der Website eine Seite angefragt und eine Challenge bekommen. Dann hat es FlareSolverr gefragt, dessen Browser die Challenge bestand und Cookies und seinen User-Agent zurückschickte. Jackett kopierte die Cookies, deren Namen mit cf_, __cf oder __ddg beginnen, setzte denselben User-Agent und fragte erneut, und die Website stellte wieder eine Challenge.

Cloudflare beschreibt sein Clearance-Cookie als „sicher an den Besucher und das Gerät gebunden, für die es ausgestellt wurde, was die Wiederverwendung auf anderen Rechnern verhindert“. Das Changelog von FlareSolverr sagt es praktisch: denselben User-Agent und denselben Proxy wie FlareSolverr nutzen. Um den User-Agent kümmert sich Jackett, die Adresse liegt bei Ihnen.

Die Wikis von FlareSolverr und Jackett nennen die üblichen Wege, auf denen zwei Programme bei verschiedenen Adressen landen.

• Ein VPN oder Proxy nur auf einer Seite: Jackett geht über einen VPN-Container ins Netz und FlareSolverr nicht, oder umgekehrt.
• IPv6 auf einer Seite: Einer erreicht die Website über IPv6, der andere über IPv4. Das Wiki von Jackett schlägt net.ipv6.conf.all.disable_ipv6=1 in jedem Container vor.
• Zwei Rechner oder zwei Netze: Das Wiki von FlareSolverr verlangt dasselbe Gerät und dieselbe IP. In Docker verlangt es beide Container im Host-Netzwerk.

Der Test dauert eine Minute. Fragen Sie aus jedem Container heraus einen IP-Echo-Dienst nach Ihrer Adresse und vergleichen Sie die beiden Antworten. Unterscheiden sie sich, ist das der Fehler.

Ein in Jackett gesetzter Proxy läuft über denselben Weg: Jackett gibt seine eigene Proxy-Einstellung mit jeder Anfrage an FlareSolverr weiter, Benutzername und Passwort eingeschlossen. Ein Proxy, der seine Adresse zwischen den Anfragen wechselt, teilt die Übergabe trotzdem, weil die Challenge von einer Adresse ausgeht und der neue Versuch von einer anderen, und diese Meldung kommt sofort zurück.

Leere Cookies von FlareSolverr

Empty cookies returned by FlareSolverr schreiben Jackett und Prowlarr beide. In Prowlarr endet die Meldung mit einem Punkt und steht oft in Unable to connect to indexer, check the log above the ValidationFailure for more details. Sie bedeutet, dass FlareSolverr ohne ein einziges Cookie geantwortet hat, sein Browser also eine andere Seite gesehen hat als Ihre App. Ihre App bekam eine Challenge, und der Browser bekam eine Seite, die gar keine Cookies setzte.

Prüfen Sie in dieser Reihenfolge.

1. Die Sprache: Auf einem System in einer anderen Sprache setzen Sie LANG=en_US für FlareSolverr. Der Triager gab genau diese Antwort auf zwei Berichte im August und September 2026, einer davon zu Version 3.5.2.
2. Was der Browser bekam: Schalten Sie LOG_LEVEL=debug und LOG_HTML=true ein. Der Triager verlangt zuerst dasselbe und findet darin oft eine gesperrte Adresse.
3. Die Adresse: Wie beim Cookie-Fehler oben müssen beide Programme vom selben Ort aus ins Netz gehen.

Challenge erkannt, aber FlareSolverr nicht eingerichtet, und die Tags in Prowlarr

Jackett schreibt Challenge detected but FlareSolverr is not configured, wenn es eine Challenge gefunden hat und keine Adresse von FlareSolverr kennt. Tragen Sie eine im Dashboard von Jackett als FlareSolverr API URL ein, zum Beispiel http://flaresolverr:8191 in Docker. Abgesehen von einem Sonderfall für vier niederländische Seiten nennen Jackett und Prowlarr etwas nur dann eine Challenge, wenn drei Dinge zutreffen. Die Antwort kommt von einem Server von Cloudflare oder DDoS-Guard, der Status ist 403 oder 503, und die Seite trägt eines von fünf bekannten Merkmalen.

Prowlarr hat keine solche Meldung. Es nutzt FlareSolverr nur, wenn der FlareSolverr-Proxy und der Indexer dasselbe Tag tragen und Cloudflare erkannt wird, und ein FlareSolverr-Proxy ohne Tags ist ausgeschaltet. Passen die Tags nicht oder ist die Challenge nach FlareSolverr noch da, meldet Prowlarr Unable to access <host>, blocked by CloudFlare Protection. Sein Log ergänzt Cloudflare protection detected for [indexer], Flaresolverr may be required. Geben Sie dem Proxy unter Settings, Indexers ein Tag und jedem Indexer, der ihn braucht, dasselbe Tag.

Keine Verbindung zum Proxy in Prowlarr, Verbindungsfehler in Jackett

In Prowlarr wird FlareSolverr als Indexer-Proxy hinzugefügt. Scheitert sein Test-Knopf, sagt die Meldung Unable to connect to proxy, und der gemeinte Proxy ist FlareSolverr. Es gibt zwei Fälle, und der Text nach dem Doppelpunkt unterscheidet sie.

Prowlarr erreicht FlareSolverr nicht, wenn der Text eine abgewiesene oder unbekannte Adresse nennt. Der Standard-Host in Prowlarr ist http://localhost:8191/, und innerhalb eines Containers ist localhost dieser Container selbst. Das Wiki von Jackett sagt dasselbe über 127.0.0.1. Legen Sie beide Container in ein Docker-Netzwerk, das Sie selbst anlegen, und nutzen Sie den Containernamen, etwa http://flaresolverr:8191/. Im Standard-Bridge-Netzwerk erreichen sich Container nur über ihre IP-Adresse. Läuft FlareSolverr auf dem Host selbst, nutzen Sie host.docker.internal, das Docker Desktop bereitstellt und --add-host host.docker.internal=host-gateway anderswo hinzufügt.

Prowlarr hat FlareSolverr erreicht, und FlareSolverr ist gescheitert, wenn der Text HTTP request failed: [500:InternalServerError] [POST] sagt. FlareSolverr antwortet mit 500, wann immer ein Befehl scheitert. Der Test bittet FlareSolverr, https://prowlarr.servarr.com/v1/ping zu laden, ein FlareSolverr, das keine Namen auflösen kann, scheitert also daran. In einem solchen Bericht stand im Log net::ERR_NAME_NOT_RESOLVED. Der Triager bat um curl -v https://prowlarr.servarr.com/v1/ping aus dem Container von FlareSolverr heraus, und das Image enthält curl.

Dieselbe 500 erscheint auch als Unable to connect to indexer, indexer's server is unavailable. Der Indexer kann dabei in Ordnung sein, weil der Fehler von FlareSolverr kam, und dessen Log sagt, warum. Jackett schreibt Error connecting to FlareSolverr server, wenn es die Adresse gar nicht erreicht, und die Lösung ist dieselbe Prüfung des Hostnamens.

Cloudflare hat die Anfrage gesperrt

FlareSolverr schreibt Cloudflare has blocked this request, und die Meldung bedeutet, was sie sagt. FlareSolverr löst sie aus, wenn der Seitentitel mit Access denied oder Attention Required! | Cloudflare beginnt oder wenn die Fehlerbox von Cloudflare auf der Seite steht, es gibt also keine Challenge zu lösen. Cloudflare dokumentiert Sperren durch eine Firewall-Regel (Fehler 1020), durch das Netz, zu dem die Adresse gehört (1005, eine Sperre der ASN), und durch die Adresse selbst (1006).

Öffnen Sie die Seite in einem normalen Browser von derselben Adresse aus, wie die Meldung sagt. Ist auch der Browser gesperrt, ändert keine Einstellung von FlareSolverr etwas daran. Versuchen Sie es nicht in einer Schleife erneut, denn Cloudflare warnt, dass wiederholte Versuche eine Sperre wegen Ratenbegrenzung verlängern können (1015). Die Sperre ist die Entscheidung der Seite. Unser Ratgeber zur Cloudflare-Seite „Sorry, you have been blocked“ erklärt, was ein gesperrter Besucher tun kann, bis hin zur Anfrage beim Betreiber der Seite.

Einen Proxy mit FlareSolverr nutzen

FlareSolverr nimmt einen Proxy pro Anfrage, pro Sitzung oder als Standard über PROXY_URL, PROXY_USERNAME und PROXY_PASSWORD. Diese drei kamen mit 3.4.2 und gelten nur für Anfragen ohne eigenen Proxy. Die Adresse braucht ihr Schema: http://, socks4:// oder socks5://.

{
  "cmd": "sessions.create",
  "session": "session-1",
  "proxy": {
    "url": "http://proxy.example:8080",
    "username": "user",
    "password": "pass"
  }
}

Die README sagt, Benutzername und Passwort funktionierten nur in sessions.create. Der Code von 3.5.2 baut dasselbe auch für eine einzelne Anfrage, und Jackett und Prowlarr schicken ihren Proxy auf diesem Weg. Vier Details entscheiden, ob der Proxy wirklich genutzt wird.

• SOCKS5 mit Passwort kann nicht funktionieren: Chrome bietet einem SOCKS5-Proxy eine einzige Anmeldemethode an, „keine Authentifizierung“, wie der Quellcode von Chromium zeigt. In unserem eigenen Test von Chrome 153 bot jede Begrüßung genau diese eine Methode an. Nutzen Sie stattdessen den HTTP-Port desselben Proxys.
• Eine Anfrage, die eine Sitzung nennt, ignoriert ihren eigenen Proxy: Es gilt der Proxy der Sitzung.
• Eine Sitzung, die FlareSolverr nicht hat, bekommt gar keinen Proxy: Eine Anfrage, die eine unbekannte Sitzung nennt, legt sie auf der Stelle an, ohne Proxy. Eine Sitzung, die nach session_ttl_minutes neu aufgebaut wird, verliert ihren Proxy ebenfalls, legen Sie Ihre Sitzungen also selbst mit sessions.create an.
• Mit Passwort trägt eine Erweiterung den Proxy: FlareSolverr schreibt dann eine kleine Chrome-Erweiterung statt eines Flags --proxy-server, und nichts anderes setzt den Proxy. Ein offenes Issue (#1751) meldet, dass ein Anführungszeichen oder ein Backslash im Passwort diese Erweiterung kaputtmacht. Google Chrome ab Version 137 ignoriert außerdem Erweiterungen, die über die Kommandozeile geladen werden. FlareSolverr fordert sie wieder an, und sein Docker-Image nutzt Chromium, wo sie weiterhin laden.

Prüfen Sie nach jeder Änderung die Ausgangsadresse. Schicken Sie FlareSolverr über dieselbe Sitzung ein request.get für eine IP-Echo-Seite und lesen Sie die Adresse im zurückgegebenen HTML. Vorher sagt Ihnen unser Proxy-Checker, ob der Proxy antwortet, HTTPS-Tunnel unterstützt und dort austritt, wo Sie es erwarten.

FlareSolverr startet nicht

Das Docker-Image bringt sein eigenes Chromium und seinen Treiber mit. Andere Installationen laden den Treiber beim ersten Browserstart von Google herunter, von googlechromelabs.github.io und storage.googleapis.com. Ein DNS-Filter, eine Firewall oder ein gesperrtes Netz stoppt diesen Download, und der Start scheitert mit Error starting Chrome. Ein Meldender sah bei einer Installation aus dem Quellcode urlopen error [Errno 104] Connection reset by peer und stellte fest, dass das offizielle Docker-Image funktionierte.

Die README führt noch TEST_URL für einen Starttest, und manche Ratschläge sagen, man solle sie ändern, aber keine Quelldatei von 3.5.2 liest sie. Der Starttest startet nur den Browser und liest seinen User-Agent. Sieben der 105 Issues in unserer Zählung melden einen Browser, der nicht startete.

FlareSolverr vom Internet fernhalten

FlareSolverr hat kein eigenes Passwort. Die README sagt: „Stellen Sie FlareSolverr NICHT ins Internet, denn es kann missbraucht werden“. Ihr Beispiel für docker run bindet den Port an 127.0.0.1, während die docker-compose.yml des Projekts 8191 auf jeder Schnittstelle veröffentlicht (Issue #1754, offen). Docker dokumentiert, dass veröffentlichte Ports geroutet werden, bevor die Regeln von ufw greifen. Im Juli 2026 meldete ein Betreiber, dass das ältere Beispiel -p 8191:8191 FlareSolverr hinter ufw offen ließ (Issue #1746). Fremde nutzten es, und die Chromium-Prozesse verursachten 228 Abbrüche wegen Speichermangels.

Zwei weitere Gewohnheiten helfen. Auf der Standardstufe des Logs gibt FlareSolverr jeden Request-Body aus, Benutzername und Passwort des Proxys eingeschlossen (Issue #1753, offen), säubern Sie ein Log also, bevor Sie es posten. Und beziehen Sie das Image nur aus der GitHub-Registry oder von Docker Hub, wie die README sagt. Ein offenes Issue warnt, dass flaresolverr.org das Projekt kopiert, ohne dazuzugehören (Issue #1703).

Was FlareSolverr nicht kann

• Captchas: Die README sagt, keiner ihrer Captcha-Löser funktioniere. Sie dokumentiert weiterhin die Meldung Captcha detected but no automatic solver is configured. und die Einstellung CAPTCHA_SOLVER, aber keine Quelldatei von 3.5.2 gibt die eine aus oder liest die andere, und keines der 105 Issues in unserer Zählung zitiert diese Meldung.
• Anderer Bot-Schutz: Die Erkennungslisten von FlareSolverr enthalten Cloudflare, DDoS-Guard und ein paar einzelne Seiten. Seiten anderer Anbieter kommen als Challenge not detected! zurück.
• Gesperrte Adressen: Eine Sperrseite bietet nichts zu lösen.
• Volumen: Jede Anfrage ohne Sitzung ist ein ganzer Browser.

Wie wir gezählt haben

Wir haben jedes Issue gelesen, das vom 26. September 2025 bis 25. September 2026 im Tracker von FlareSolverr eröffnet wurde, über die öffentliche GitHub-API, 105 insgesamt. Titel und Text jedes Issues haben wir mit den genauen Meldungen oben abgeglichen, und ein Issue kann mehrere zitieren. Die 37, die keine zitieren, sind Sicherheitsberichte, Probleme mit Paketen, Anfragen zur API, Fragen zum Umgang mit Proxies und Fehlerberichte ohne bekannte Meldung. Von den 105 Meldenden sagten 34, sie nutzten Docker, und 39, sie täten es nicht.

Quellen

• README von FlareSolverr, Projekt FlareSolverr. Version 3.5.2 vom 12. September 2026, gelesen am 26. und 27. September 2026. Sie behandelt die Einstellungen zu Proxy, Sitzung, Zeitgrenze und Umgebung und sagt „DO NOT expose FlareSolverr to the internet“ und „At this time none of the captcha solvers work“.
• src/flaresolverr_service.py, src/utils.py, src/sessions.py und docker-compose.yml, FlareSolverr 3.5.2, gelesen am 26. September 2026. Sie enthalten jede Meldung von FlareSolverr, den festen Status 200, die Proxy-Erweiterung und den Code der Sitzungen.
• Changelog von FlareSolverr und Versionen, gelesen am 26. September 2026. Sie datieren jede Änderung und sagen „make sure your client uses the same User-Agent header and Proxy that FlareSolverr uses“.
• Wiki von FlareSolverr, Troubleshooting, zuletzt bearbeitet am 25. August 2026, gelesen am 26. September 2026. „FlareSolverr should be running on the same device and using the same IP as the app making the request“.
• Issue-Tracker von FlareSolverr, gelesen am 26. September 2026. Issues #1253, #1361, #1582, #1639, #1664, #1669, #1703, #1731, #1746, #1751, #1753, #1754, #1761 und #1780 sowie Diskussion #1565.
• FlareSolverrSharp 4.0.0, ClearanceHandler.cs, 11. August 2026, gelesen am 26. September 2026. Enthält die Meldungen von Jackett und wann jede ausgelöst wird.
• Quellcode von Jackett, ServerConfig.cs, gelesen am 26. September 2026. Setzt „FlareSolverrMaxTimeout = 55000“ und den Proxy, den Jackett an FlareSolverr weitergibt.
• Wiki von Jackett, Troubleshooting, zuletzt bearbeitet am 23. August 2026, gelesen am 26. September 2026. „In most cases this error is caused when Jackett and FlareSolverr are on different networks“.
• Quellcode von Prowlarr, der FlareSolverr-Indexer-Proxy, 13. September 2026: FlareSolverr.cs, gelesen am 26. September 2026, enthält „Empty cookies returned by FlareSolverr.“ und die Testseite; FlareSolverrSettings.cs, gelesen am 27. September 2026, enthält den Standard-Host und den Bereich der Zeitgrenze.
• Servarr-Wiki, FAQ zu Prowlarr, aktualisiert am 5. September 2026, gelesen am 26. September 2026. „A Flaresolverr proxy is disabled if no tags are used“.
• Dokumentation von Cloudflare, Clearance, aktualisiert am 6. Juli 2026, und Challenge Pages, aktualisiert am 6. Juli 2026, gelesen am 26. und 27. September 2026. Das Cookie ist „securely tied to the specific visitor and device it was issued to“, und bei einer Managed Challenge gilt: „if Cloudflare detects non-human attributes from the visitor's browser, they may be required to interact with the challenge to solve it.“
• Dokumentation von Cloudflare, Fehler 1020, mit den Fehlern 1005, 1006 und 1015, gelesen am 26. September 2026.
• Dokumentation von Docker, Bridge-Netzwerke, Paketfilter und Firewalls und docker container run, gelesen am 26. September 2026.
• Quellcode von Chromium, socks5_client_socket.cc, gelesen am 26. September 2026. Die Begrüßung von SOCKS5 bietet nur „no authentication“ an.
• Ankündigung zu --load-extension bei Chromium Extensions, 4. April 2025. Der Schalter funktioniert in den Markenversionen von Chrome ab Chrome 137 nicht mehr und in Chromium weiterhin.
• Gemessen von HProxy: die Zählung von 105 Issues zu FlareSolverr am 26. September 2026 und unser Test von Chrome 153 gegen einen SOCKS5-Testproxy auf diesem Rechner am 15. September 2026. Die Skripte und Ergebnisse liegen bei der Recherche zu dieser Seite.