Upload blijft mislukken? Los veelvoorkomende fouten op

Een mislukte upload valt bijna altijd in een van vijf categorieën: netwerkinstabiliteit (Wi-Fi-uitval, ISP-omleiding), geheugenuitputting van de browser (Chrome die een tabblad afkapt op 2 GB RAM), service-side rate limiting of quota, een corrupt bronbestand, of een antivirus/firewall die uitgaande verzoeken blokkeert. Begin met het Network-tabblad van DevTools om de werkelijke HTTP-statuscode van het mislukte verzoek te bekijken. Een 413 is "payload te groot". Een 502 of 503 is de dienst. Een "ERR_CONNECTION_RESET" is uw netwerk. Elk vraagt om een andere oplossing.

Lees de werkelijke fout, niet de generieke melding

De meeste upload-UI's tonen "Upload mislukt" en daarmee is het klaar. Daar heb je niets aan. Open DevTools van de browser (F12 of Cmd+Option+I), schakel naar het Network-tabblad en bekijk het mislukte verzoek. De statuscode vertelt waar het probleem zit: 400-reeks betekent uw kant (413 te groot, 401 auth, 403 verboden), 500-reeks betekent hun kant (502 bad gateway, 503 slow down, 504 timeout). Verbindingsfouten als ERR_CONNECTION_RESET of net::ERR_NETWORK_CHANGED betekenen dat de TCP-verbinding tijdens de overdracht is gestorven.

Maak een screenshot van het mislukte verzoek en de antwoordheaders voordat u iets sluit. Als u escaleert naar support, wijzen die headers het probleem meestal aan.

Wi-Fi-uitval: de stille moordenaar

Laptop-Wi-Fi-chips wisselen soms tussen access points en tussen banden (2,4 GHz en 5 GHz). Elke wissel breekt de TCP-verbinding voor een fractie van een seconde, wat een single-stream-upload doodt. Uploaddiensten die chunked, hervatbare uploads implementeren (op tus.io of S3 multipart) overleven dit; enkelvoudige POST-uploads niet.

Kun je bedraden, doe het. Ethernet wisselt niet. Lukt dat niet, blijf dan minstens in één kamer en schakel "Auto-switch SSID" of mesh-band-steering uit tijdens de upload. Laat een continue ping naar 1.1.1.1 lopen in een andere terminal en let op gaten; in die gaten gaan uploads stuk.

Browsercrashes en tab-eviction

Chrome doodt tabbladen die een geheugendrempel overschrijden, doorgaans rond 2 tot 4 GB per tab afhankelijk van het beschikbare RAM. Een 10 GB-bestand uploaden via een browser die het hele bestand in geheugen buffert (slechte implementatie) crasht. Uploaden via een browser die chunks streamt (goede implementatie, met de slice()-methode van de File API) gebruikt een paar honderd MB RAM ongeacht de bestandsgrootte.

Als je browser blijft crashen op grote uploads, probeer dan Firefox, dat historisch grote File API-uploads aankan met minder geheugendruk dan Chromium. Zorg dat de dienst chunked uploads gebruikt; als een 5 GB-bestand in één Blob wordt geladen vóór POST, zit het ontwerpprobleem dáár.

Sluit elk ander tabblad. Herstart de browser voor de start. Schakel extensies uit (ad blockers, privacy-extensies en wachtwoordmanagers injecteren soms in upload-streams en breken die).

Bedrijfsfirewalls en proxy's

Bedrijfsnetwerken voeren vaak deep packet inspection, traffic shaping of proxyservers uit die certificaten injecteren. Symptomen: uploads slagen voor kleine bestanden maar falen vanaf een specifieke grootte (vaak 100 MB of 1 GB), of de fout luidt "SSL handshake failed" of "certificate verification failed".

Test door te uploaden vanaf een mobiele hotspot (buiten het bedrijfsnetwerk). Werkt het daar, dan zit het probleem aan jouw kant. Opties: vraag IT om het uploadeindpunt van de dienst toe te voegen aan de allowlist, gebruik een VPN (indien toegestaan) om de shaper te omzeilen, of stap over op een persoonlijk netwerk.

Zscaler, Cisco Umbrella en Palo Alto-appliances zijn veelvoorkomende boosdoeners. Ze inspecteren bestanden vaak boven een groottedrempel en raken uitgeput op grote streams.

Antivirus die de uitgaande stream scant

Windows Defender, Bitdefender, Norton en Kaspersky kunnen uitgaand HTTPS-verkeer scannen door TLS te onderscheppen. Bij grote uploads kan de scan zelf de doorvoer met 40 tot 60 procent vertragen, en bij sommige versies introduceert hij time-outs die de verbinding doden.

Schakel realtime-webbescherming tijdelijk uit (niet de hele antivirus, alleen het HTTPS-inspectieonderdeel) en probeer opnieuw. Slaagt de upload, voeg dan het domein van de overdrachtsdienst toe aan de uitsluitingslijst van de antivirus. Laat webbescherming niet permanent uit staan.

Service-side rate limits

Krijgt u 429- of 503-antwoorden, dan throttelt de dienst u. Mogelijke redenen: u draait te veel parallelle chunks (zak terug van 8 naar 4 workers), u bent een gratis-tier dagquotum tegengekomen (WeTransfer Free komt uit op 2 GB per overdracht maar heeft impliciete dagvolumelimieten), of u zit op een gedeeld IP dat is gemarkeerd (gangbaar op hotel- en café-Wi-Fi die misbruikt zijn).

Wacht 15 minuten en probeer opnieuw. Of wissel van netwerk. Of wissel van dienst.

Corrupt bronbestand

Soms is het bestand zelf het probleem. Filesystem-corruptie (een bad sector op een externe schijf, een afgebroken kopie) levert een bestand op dat de eerste paar MB prima leest en daarna I/O-fouten geeft. De upload blijft elke poging op hetzelfde percentage hangen.

Test door het bestand eerst naar een andere lokale schijf te kopiëren. Faalt de kopie op hetzelfde percentage, dan ligt het aan de bron. Run chkdsk op Windows of diskutil verifyDisk op macOS op de bronschijf. Voor kritieke bestanden: herstel uit een bekende-goede kopie voordat u opnieuw probeert te uploaden.

Systeemklok, TLS-fouten en VPN-sessies

Als je systeemklok meer dan een paar minuten afwijkt, faalt TLS-certificaatvalidatie en geeft de upload een fout zoals "certificaat nog niet geldig". Forceer een NTP-sync: sntp -sS time.apple.com op macOS, of Instellingen > Tijd & taal > Datum & tijd > Nu synchroniseren op Windows.

Sommige VPN-clients (vooral gratis varianten) verbreken langlopende TCP-verbindingen na 5 tot 10 minuten omdat hun sessietokens vernieuwen. Een upload van 20 minuten sterft dan stilletjes. Schakel over naar een betaalde VPN met betere sessieafhandeling (Mullvad, ProtonVPN, IVPN), of verbreek de VPN tijdens uploads als de dienst zelf end-to-end TLS-encryptie gebruikt. HexaTransfer versleutelt met AES-256-GCM client-side voordat het bestand je browser verlaat, dus extra VPN-encryptie is dubbele beveiliging, geen vereiste.

Probeer een dienst die chunks automatisch opnieuw probeert

Als u de voor de hand liggende lokale problemen hebt opgelost en uploads blijven falen, kan de dienst zelf onderbrekingen niet goed afhandelen. Een dienst met automatisch opnieuw proberen per chunk en hervatbare sessiestatus blijft draaien door de soort hapering (een Wi-Fi-wissel, een korte ISP-omleiding) die single-stream-uploaders doodt. HexaTransfer voert parallelle chunked uploads uit met opnieuw proberen per chunk en overleeft de meeste korte netwerkgebeurtenissen zonder enige handmatige interventie.

Probeer het op hexatransfer.com — gratis, geen account, tot 10 GB.