Time-outfouten bij overdracht: oorzaken en oplossingen

Time-outfouten bij bestandsoverdrachten komen uit een van vier plaatsen: het HTTP-verzoek van de client wachtte te lang op een serverreactie (doorgaans 30 tot 120 seconden), de server wachtte te lang op data van de client (gebruikelijk bij trage uploads), een tussenliggende proxy of load balancer verbrak de verbinding (AWS ALB standaard is 60 seconden), of het OS beëindigde een inactieve TCP-verbinding. 504 Gateway Timeout betekent dat de load balancer de origin niet kon bereiken. 408 Request Timeout betekent dat de server ophield te wachten op jouw data. ERR_CONNECTION_TIMED_OUT betekent dat de TCP-handshake nooit voltooide. Elk heeft een afzonderlijke oplossing.

Lees het time-outtype uit de fout

Verschillende time-outs vereisen verschillende oplossingen:

504 Gateway Timeout: Tussenliggende proxy of load balancer time-out. Probleem aan de servicekant, meestal voorbijgaand. Probeer opnieuw of switch van regio.
408 Request Timeout: Server wachtte op clientdata. Je upload stagneerde midden in een verzoek.
524 (Cloudflare): Origin reageerde niet binnen 100 seconden. Servicekant.
502 Bad Gateway: Proxy kreeg een ongeldig antwoord van origin. Service-outage of lopende deployment.
ERR_CONNECTION_TIMED_OUT: Je TCP-verbinding met de server voltooide nooit. Netwerk of firewall.
ERR_NETWORK_CHANGED: Je netwerk wisselde midden in de verbinding. Wi-Fi-roaming of VPN-verbreken.

DevTools' Network-tabblad toont de exacte respons, timing en statuscode. Maak een screenshot voor je iets sluit.

Wi-Fi-roaming beëindigt langlopende uploads

Laptop Wi-Fi-chips wisselen automatisch tussen banden en access points. Elke wissel verbreekt de huidige TCP-verbinding. Single-stream uploads gaan direct dood; chunked uploads overleven als de dienst per chunk herprobeert.

Oplossing: gebruik Ethernet voor uploads boven 2 GB. Als dat niet kan, schakel band-steering uit op je router (stel in op "5 GHz only" voor je laptop's SSID) en blijf in één kamer. Op macOS zet je "Automatisch verbinden" uit voor alle SSID's behalve je primaire om te voorkomen dat je halverwege naar een sterkere verbinding springt.

Load balancer time-outs aan de servicekant

AWS Application Load Balancer standaard idle time-out is 60 seconden. Nginx standaard proxy_read_timeout is 60 seconden. Diensten die deze instellingen niet goed hebben afgesteld, kappen uploads af die kort pauzeren (voor versleuteling, voor een trage schijflezing aan de bron) bij de 60-secondengrens.

Als je 504-fouten ziet bij een specifieke dienst, is het doorgaans hun slecht geconfigureerde load balancer. Niets wat je aan de clientkant kunt doen behalve opnieuw proberen. Chunked uploaders verwerken dit transparant door de mislukte chunk opnieuw te proberen; single-stream uploaders mislukken volledig en je begint opnieuw.

Bedrijfsproxy time-outs

Zscaler, Blue Coat, Palo Alto en andere bedrijfsproxy's handhaven hun eigen time-outs, doorgaans 30 seconden tot 5 minuten inactief. Als je upload iets doet wat de proxy als inactief beschouwt (versleutelingspauze, chunk-retry-vertraging), verbreekt de proxy de verbinding.

Diagnoseer door buiten het bedrijfsnetwerk te uploaden (telefoon-hotspot). Als time-outs verdwijnen, is de proxy de oorzaak. Vraag IT om het domein van de overdrachtsdienst te allowlisten en inspectie voor die domeinen te omzeilen. De alternatieve oplossing is persoonlijk netwerk of een VPN-tunnel naar huis.

TCP keepalive op OS-niveau

Linux stuurt TCP keepalive-pakketten standaard pas na 2 uur inactiviteit — nutteloos voor bestandsoverdracht. macOS en Windows hebben vergelijkbare standaarden. Voor zeer lange uploads op instabiele netwerken implementeren sommige diensten keepalive op applicatieniveau via WebSocket ping-frames of periodieke lege chunks. Als de dienst dat niet doet, kunnen lange uploads via een NAT-firewall (standaard 5 minuten UDP-sessie time-out op de meeste thuisrouters) verbreken wanneer de NAT-entry verloopt.

VPN-sessietoken-vernieuwing

Sommige VPN-clients vernieuwen sessietokens elke 5 tot 15 minuten. Bij buggy clients verbreekt de vernieuwing het onderliggende TCP-tunnel een halve seconde. Lange uploads sterven dan.

Betaalde VPN's (Mullvad, ProtonVPN Plus, IVPN) verwerken dit schoon. Gratis VPN's vaak niet. Als je consistent time-outs ziet op de 10-minutengrens, verdacht dan VPN-vernieuwing. Verbreek de VPN voor de upload als de overdrachtsdienst al TLS 1.3 end-to-end versleuteling gebruikt.

Mobiele handoffs

Mobiele data wisselt van cel terwijl je beweegt. Elke handoff (a) behoudt het IP via mobiliteitsbeheer (transparant) of (b) wijst een nieuw IP toe (verbinding verbreekt). Op LTE zijn de meeste handoffs transparant. Op 5G, met name mmWave, kunnen handoffs naar sub-6 of LTE-fallback het IP wijzigen en verbindingen beëindigen.

Als je uploadt vanuit een rijdend voertuig op mobiel, verwacht verbrekingen. Chunked-hervatbare uploaders verwerken dit goed; single-stream uploaders niet.

WAF-time-outs

Als een dienst achter een Web Application Firewall zit (Cloudflare WAF, AWS WAF, ModSecurity), kan de WAF een langlopende upload als verdacht markeren en verbreken. Symptomen: uploads slagen bij kleine formaten, mislukken bij een specifieke drempelwaarde (vaak 1 GB of 10 GB afhankelijk van WAF-configuratie), met 403- of 502-reacties.

Niets wat je aan de clientkant kunt doen. Rapporteer aan de dienst. Een goed afgestelde WAF staat chunked uploads toe zonder ze te markeren.

Browser standaard time-outs

Browsers hebben ook verzoek-time-outs, hoewel ze doorgaans royaal zijn voor uploads. Chrome en Firefox geven XHR- en fetch-verzoeken standaard onbeperkte tijd, maar beëindigen inactieve verbindingen wel na 5 minuten in sommige configuraties.

Als de JavaScript van de dienst xhr.timeout = 30000 (30 seconden) per chunk instelt, mislukken trage chunks. Dit is een servicekant-bug; rapporteer het.

Antivirus die HTTPS-verkeer inspecteert

Windows Defender met "HTTPS-inspectie" ingeschakeld, Norton, Bitdefender en vergelijkbare programma's MITM-en HTTPS-verbindingen om inhoud te scannen. Bij grote uploads voegt de scan zelf latentie toe die chunks voorbij server-side time-outs kan duwen.

Schakel HTTPS-inspectie tijdelijk uit (niet de volledige AV, alleen de HTTPS-scan) tijdens grote uploads. Als uploads slagen, voeg dan het domein van de overdrachtsdienst permanent toe aan de AV-uitsluitingslijst.

Herprobelogica en exponentiële terugval

Goed gebouwde overdrachtsclients proberen mislukte chunks opnieuw met exponentiële terugval: 1 seconde, dan 2, dan 4, dan 8. Een kort netwerkprobleem herstelt transparant. Clients zonder herprobelogica mislukken bij de eerste fout.

Als je een dienst gebruikt die niet automatisch herprobeert, zie je meer time-out-fouten. Kies een client of dienst die herproberingslogica voor je verwerkt.

Probeer het gewoon opnieuw na 15 minuten

Sommige time-outs zijn voorbijgaand: een Cloudflare-edge-hapering, een service-deployment, een verstopt transit-link. Probeer opnieuw na 15 minuten voor je escaleert. Als het opnieuw mislukt, switch naar een ander netwerk om te isoleren of het probleem van jou is of van de dienst.

Kies een dienst met robuuste herpoging

Voor grote bestanden via onbetrouwbare netwerken wil je een dienst met herpoging per chunk, hervatbare sessiestatus en geen agressieve server-side time-out. HexaTransfer draait parallelle chunked uploads met per-chunk herpoging en AES-256-GCM-versleuteling aan de clientkant, zodat een upload van 10 GB via een spottachtige verbinding de getroffen chunks transparant herprobeert in plaats van de volledige overdracht te laten mislukken bij één netwerkhapering.

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