Upload schlägt fehl? Häufige Transferfehler beheben

Ein fehlgeschlagener Upload fällt fast immer in eine von fünf Kategorien: Netzwerkinstabilität (WLAN-Abbruch, ISP-Umleitung), Browser-Speichererschöpfung (Chrome beendet einen Tab bei 2 GB RAM), dienstseitige Ratenlimitierung oder Kontingentüberschreitung, beschädigte Quelldatei oder Antivirus/Firewall, die ausgehende Anfragen blockiert. Prüfen Sie zunächst den Netzwerk-Tab in den DevTools nach dem tatsächlichen HTTP-Statuscode der fehlgeschlagenen Anfrage. Ein 413 bedeutet „Nutzlast zu groß". Ein 502 oder 503 kommt vom Dienst. ERR_CONNECTION_RESET kommt von Ihrem Netzwerk. Jede Ursache hat eine andere Lösung.

Den tatsächlichen Fehler lesen, nicht die allgemeine Meldung

Die meisten Upload-Oberflächen zeigen „Upload fehlgeschlagen" und lassen es damit gut sein. Das ist nutzlos. Öffnen Sie die Browser-DevTools (F12 oder Cmd+Option+I), wechseln Sie zum Netzwerk-Tab und beobachten Sie die fehlgeschlagene Anfrage. Der Statuscode zeigt, wo das Problem liegt: 400er bedeutet Ihre Seite (413 zu groß, 401 nicht authentifiziert, 403 verboten), 500er bedeutet die Gegenseite (502 Bad Gateway, 503 Slow Down, 504 Timeout). Verbindungsfehler wie ERR_CONNECTION_RESET oder net::ERR_NETWORK_CHANGED bedeuten, dass die TCP-Verbindung während der Übertragung gestorben ist.

Machen Sie einen Screenshot der fehlgeschlagenen Anfrage und ihrer Antwortheader, bevor Sie alles schließen. Wenn Sie den Support kontaktieren, liefern diese Header meist den genauen Hinweis auf die Ursache.

WLAN-Abbrüche: der stille Killer

Laptop-WLAN-Chips roamen zwischen Access Points und zwischen Frequenzbändern (2,4 GHz und 5 GHz). Jeder Roaming-Vorgang unterbricht die TCP-Verbindung für einen Bruchteil einer Sekunde — das tötet einen Single-Stream-Upload. Transferdienste mit Chunked, wiederaufnehmbaren Uploads (tus.io-basiert, S3 Multipart) überstehen das; einzelne POST-Uploads nicht.

Wenn möglich, verkabeln Sie sich. Ethernet roamt nicht. Wenn das nicht möglich ist, bleiben Sie zumindest in einem Raum und deaktivieren Sie während des Uploads „Automatisches SSID-Wechseln" oder Mesh-Band-Steering. Führen Sie in einem anderen Terminal ein dauerhaftes Ping auf 1.1.1.1 aus und beobachten Sie Lücken — diese Lücken sind der Grund, warum Ihre Uploads sterben.

Browser-Abstürze und Tab-Entleerung

Chrome beendet Tabs, wenn sie einen Speicherschwellenwert überschreiten — typischerweise 2 bis 4 GB pro Tab je nach verfügbarem RAM. Das Hochladen einer 10-GB-Datei über einen Browser, der die gesamte Datei in den Speicher puffert (schlechte Implementierung), stürzt ab. Das Hochladen über einen Browser, der Chunks streamt (gute Implementierung, nutzt die slice()-Methode der File API), verwendet unabhängig von der Dateigröße nur einige hundert MB RAM.

Wenn Ihr Browser bei großen Uploads immer wieder abstürzt, versuchen Sie Firefox — dieser verarbeitet große File-API-Uploads historisch mit weniger Speicherdruck als Chromium. Stellen Sie sicher, dass der Dienst Chunked Uploads verwendet; wird eine 5-GB-Datei vor dem POST in einen einzigen Blob geladen, liegt darin das Designproblem.

Schließen Sie alle anderen Tabs. Starten Sie den Browser vor dem Beginn neu. Deaktivieren Sie Erweiterungen — Werbeblocker, Datenschutzerweiterungen und Passwort-Manager injizieren manchmal in Upload-Streams und unterbrechen diese.

Unternehmens-Firewalls und Proxys

Unternehmens-Netzwerke betreiben häufig Deep-Packet-Inspection, Traffic-Shaping oder Proxy-Server, die Zertifikate einschleusen. Symptome: Uploads gelingen bei kleinen Dateien, schlagen aber bei einer bestimmten Größe fehl (oft 100 MB oder 1 GB), oder der Fehler lautet „SSL-Handshake fehlgeschlagen" oder „Zertifikatsverifikation fehlgeschlagen".

Prüfen Sie, ob der Upload über den Hotspot Ihres Smartphones (außerhalb des Unternehmensnetzwerks) funktioniert. Gelingt er dort, liegt das Problem auf Ihrer Seite. Optionen: IT bitten, den Upload-Endpunkt des Dienstes auf die Positivliste zu setzen, ein VPN nutzen (wenn erlaubt) um den Shaper zu umgehen, oder auf ein privates Netzwerk wechseln.

Zscaler, Cisco Umbrella und Palo Alto Appliances sind häufige Verursacher. Sie inspizieren oft Dateien oberhalb eines Größenschwellenwerts und laufen bei großen Streams in Timeouts.

Antivirus, der den ausgehenden Stream scannt

Windows Defender, Bitdefender, Norton und Kaspersky können ausgehenden HTTPS-Traffic durch TLS-Abfangen scannen. Bei großen Uploads kann der Scan selbst den Durchsatz um 40 bis 60 Prozent reduzieren und auf manchen Versionen Timeouts einführen, die die Verbindung abbrechen.

Deaktivieren Sie vorübergehend den Echtzeit-Web-Schutz (nicht den gesamten Antivirus, nur die HTTPS-Inspektionskomponente) und versuchen Sie es erneut. Gelingt der Upload, fügen Sie die Domain des Transferdiensts zur Ausnahmeliste des Antivirus hinzu. Lassen Sie den Web-Schutz nicht dauerhaft deaktiviert.

Dienstseitige Ratenlimits

Erhalten Sie 429- oder 503-Antworten, drosselt der Dienst Sie. Mögliche Gründe: Sie betreiben zu viele parallele Chunks (reduzieren Sie von 8 auf 4 Worker), Sie haben ein Free-Tier-Tageskontingent überschritten (WeTransfer Free hat implizite Tagesvolumenlimits), oder Sie befinden sich auf einer gemeinsam genutzten IP, die markiert wurde (üblich in Hotel- und Café-WLANs).

Warten Sie 15 Minuten und versuchen Sie es erneut. Oder wechseln Sie das Netzwerk. Oder wechseln Sie den Dienst.

Beschädigte Quelldatei

Selten, aber manchmal ist die Datei selbst das Problem. Dateisystem-Fehler (defekter Sektor auf einer externen Festplatte, unterbrochene Kopie) erzeugen eine Datei, die für die ersten paar MB problemlos gelesen wird und danach I/O-Fehler zurückgibt. Der Upload stockt bei jedem Versuch an derselben Prozent-Marke.

Kopieren Sie die Datei zuerst auf einen anderen lokalen Datenträger. Schlägt die Kopie an derselben Stelle fehl, liegt das Problem an der Quelle. Führen Sie chkdsk unter Windows oder diskutil verifyDisk unter macOS auf dem Quelldatenträger aus. Bei kritischen Dateien stellen Sie eine bekannt-gute Kopie wieder her, bevor Sie erneut versuchen hochzuladen.

Datum, Uhrzeit und TLS-Zertifikatsfehler

Ist Ihre Systemuhr um mehr als wenige Minuten falsch, schlägt die TLS-Zertifikatsvalidierung fehl, und Uploads brechen mit „Zertifikat noch nicht gültig" oder ähnlichem ab. Macs und Windows synchronisieren in der Regel automatisch via NTP — nach einem langen Ruhezustand oder einer leeren Motherboard-Batterie driften Uhren jedoch.

Erzwingen Sie eine NTP-Synchronisierung: sntp -sS time.apple.com unter macOS, oder Einstellungen > Zeit und Sprache > Datum und Uhrzeit > Jetzt synchronisieren unter Windows.

VPNs, die still versagen

Manche VPN-Clients (besonders kostenlose) beenden lang laufende TCP-Verbindungen nach 5 bis 10 Minuten, weil ihre Session-Tokens erneuert werden. Ein 2-GB-Upload, der 20 Minuten braucht, stirbt beim Token-Refresh — still und ohne Meldung. Entweder wechseln Sie zu einem bezahlten VPN mit besserem Session-Management (Mullvad, ProtonVPN, IVPN), oder Sie trennen das VPN während Uploads, wenn der Dienst bereits Ende-zu-Ende-TLS-verschlüsselt ist.

Ende-zu-Ende-verschlüsselte Dienste bedeuten, dass Sie für die Vertraulichkeit während der Übertragung kein VPN benötigen. HexaTransfer verschlüsselt beispielsweise mit AES-256-GCM auf dem Client, bevor die Datei Ihren Browser verlässt — VPN-Verschlüsselung zusätzlich ist doppelt gesichert, nicht notwendig.

Einen Dienst nutzen, der Chunks automatisch wiederholt

Haben Sie die offensichtlichen lokalen Probleme behoben und schlagen Uploads immer noch fehl, verarbeitet der Dienst möglicherweise Unterbrechungen nicht gut. Ein Dienst mit automatischem Chunk-Retry und wiederaufnehmbarem Session-Zustand läuft durch die Art von Aussetzern durch — ein WLAN-Roaming-Vorgang, eine kurze ISP-Umleitung — die Single-Stream-Uploader töten. HexaTransfer betreibt parallele Chunked Uploads mit Chunk-Retry und übersteht die meisten kurzen Netzwerkereignisse ohne manuellen Eingriff.

Auf hexatransfer.com testen — kostenlos, ohne Konto, bis 10 GB.