[SSL: UNEXPECTED_EOF_WHILE_READING] EOF occurred in violation of protocol

Mit OpenSSL 3 zeigt Python den Reason-Code „[SSL: UNEXPECTED_EOF_WHILE_READING]“; mit OpenSSL 1.1.1 lautet der Text nur „EOF occurred in violation of protocol“. Danach folgt eine Quellcode-Position wie „(_ssl.c:1082)“.

Python ssl module (OpenSSL) — ssl.SSLEOFError, SSL_R_UNEXPECTED_EOF_WHILE_READING

Was der Fehler bedeutet

Die Gegenstelle hat die TCP-Verbindung geschlossen, während Python noch im TLS-Handshake war (oder gerade Daten las), ohne einen TLS-Alert oder close_notify zu senden. OpenSSL wertet dieses stille Schließen als Protokollverletzung. Python kann nicht wissen, warum die Gegenstelle die Verbindung beendet hat; der Grund liegt beim Server, bei einem Proxy oder bei einer Firewall dazwischen.

Warum der Fehler auftritt

• Der Server verwirft Handshakes, die ihm nicht gefallen

  häufig

  Manche Server und Load Balancer schließen die Verbindung, statt einen Alert zu senden, wenn dem ClientHello SNI fehlt, es keine akzeptable Version oder Cipher anbietet oder der Name nicht konfiguriert ist.

• Ein Proxy, eine Firewall oder ein VPN kappt die Verbindung

  häufig

  Falsche Proxy-Einstellungen (HTTPS_PROXY, das auf einen TLS-Port des Proxys zeigt, fehlendes NO_PROXY für interne Hosts), Deep Packet Inspection, die das Ziel blockiert, oder VPN-Clients beenden die TCP-Verbindung oft stillschweigend.

• Rate Limiting oder Bot-Schutz

  gelegentlich

  APIs und CDNs unter Last oder Anti-Bot-Systeme, denen der TLS-Fingerabdruck von Python missfällt, können Verbindungen zurücksetzen, statt einen HTTP-Fehler zurückzugeben.

• Der Server hat die Verbindung mitten in der Antwort geschlossen

  gelegentlich

  Tritt der Fehler beim Lesen einer Antwort auf, hat der Server oder ein Proxy die Verbindung ohne close_notify beendet, zum Beispiel nach einem Timeout oder dem Absturz eines Workers.

So behebst du den Fehler

1. 1.

   Handshake mit openssl s_client nachstellen

   Wird auch s_client getrennt, variiere SNI und die TLS-Version, um zu sehen, woran sich der Server stört; funktioniert s_client, vergleiche seine Einstellungen mit deinem Python-Client (Proxy, SNI, Versionen).

   # Does a plain OpenSSL handshake work from the same machine?
   openssl s_client -connect api.example.com:443 -servername api.example.com -brief </dev/null
   # Without SNI, and pinned to TLS 1.2, to see what the server objects to
   openssl s_client -connect api.example.com:443 -noservername -brief </dev/null
   openssl s_client -connect api.example.com:443 -servername api.example.com -tls1_2 -brief </dev/null

2. 2.

   Proxy-Umgebungsvariablen prüfen

   requests, urllib und pip berücksichtigen HTTPS_PROXY und NO_PROXY. Korrigiere das Schema der Proxy-URL und nimm interne Hosts aus, die direkt erreicht werden müssen.

   env | grep -i -E '^(https?|no|all)_proxy='
   # Proxy URLs should normally be http:// (CONNECT tunnel), and internal hosts listed in NO_PROXY
   export HTTPS_PROXY=http://proxy.example.net:3128
   export NO_PROXY=localhost,127.0.0.1,.internal.example.com

3. 3.

   Wiederholen, wenn die Ursache vorübergehend ist

   Bei Rate Limiting und instabilen Netzwerken machen Wiederholungen mit Backoff aus sporadischen Resets langsamere Erfolge; einen Server, der den Handshake immer ablehnt, reparieren sie nicht.

   import requests
   from requests.adapters import HTTPAdapter
   from urllib3.util.retry import Retry
   
   session = requests.Session()
   session.mount("https://", HTTPAdapter(max_retries=Retry(total=3, backoff_factor=1)))
   session.get("https://api.example.com/")

← Gesamte Signaturfehler-Datenbank durchsuchen