Erreurs de délai d'attente de transfert : causes et solutions

Les erreurs de timeout lors des transferts de fichiers proviennent de l'un de ces quatre endroits : la requête HTTP du client a attendu trop longtemps la réponse du serveur (en général 30 à 120 secondes), le serveur a attendu trop longtemps les données du client (courant lors des envois lents), un proxy ou un équilibreur de charge intermédiaire a coupé la connexion (l'AWS ALB est réglé par défaut à 60 secondes), ou le système d'exploitation a tué une connexion TCP inactive. Un 504 Gateway Timeout signifie que l'équilibreur de charge n'a pas pu joindre l'origine. Un 408 Request Timeout signifie que le serveur a abandonné l'attente de vos données. Un ERR_CONNECTION_TIMED_OUT signifie que la poignée de main TCP n'a jamais abouti. Chacun a une correction distincte.

Lisez le type de timeout dans le message d'erreur

Différents timeouts nécessitent différentes corrections :

• 504 Gateway Timeout : proxy ou équilibreur de charge intermédiaire dépassé. Problème côté service, généralement transitoire. Réessayez ou changez de région.
• 408 Request Timeout : le serveur a abandonné l'attente des données client. Votre envoi a calé en cours de requête.
• 524 (Cloudflare) : l'origine n'a pas répondu dans les 100 secondes. Côté service.
• 502 Bad Gateway : le proxy a reçu une réponse invalide de l'origine. Panne de service ou déploiement en cours.
• ERR_CONNECTION_TIMED_OUT : votre connexion TCP au serveur n'a jamais abouti. Réseau ou pare-feu.
• ERR_NETWORK_CHANGED : votre réseau a changé en cours de connexion. Bascule Wi-Fi ou déconnexion VPN.

L'onglet Réseau des DevTools affiche la réponse exacte, le timing et le code de statut. Faites une capture d'écran avant de fermer quoi que ce soit.

Le Wi-Fi en itinérance tue les envois prolongés

Les puces Wi-Fi des ordinateurs portables basculent automatiquement entre bandes et points d'accès. Chaque bascule coupe la connexion TCP en cours. Les envois en flux unique meurent immédiatement ; les envois par fragments survivent si le service réessaie par fragment.

Correctif : branchez un câble Ethernet pour les envois de plus de 2 Go. Si vous ne pouvez pas, désactivez le band-steering sur votre routeur (passez-le en "5 GHz uniquement" pour le SSID de votre ordinateur) et restez dans une seule pièce. Sur macOS, désactivez la "Connexion automatique" pour tous les SSID sauf le principal, pour éviter que l'appareil parte chercher un signal plus fort en cours d'envoi.

Timeouts côté service de l'équilibreur de charge

L'AWS Application Load Balancer règle le timeout d'inactivité à 60 secondes par défaut. Nginx règle proxy_read_timeout à 60 secondes par défaut. Les services qui n'ont pas ajusté ces paramètres coupent les envois qui marquent brièvement une pause (pour le chiffrement, pour une lecture disque lente sur la source) à la marque des 60 secondes.

Si vous voyez des timeouts 504 sur un service spécifique, c'est généralement leur équilibreur de charge mal configuré. Rien à faire côté client, hormis réessayer. Les outils d'envoi par fragments gèrent cela de façon transparente en réessayant le fragment échoué ; les outils en flux unique échouent complètement et vous devez recommencer.

Timeouts du proxy d'entreprise

Zscaler, Blue Coat, Palo Alto et autres proxies d'entreprise appliquent leurs propres timeouts, généralement entre 30 secondes et 5 minutes d'inactivité. Si votre envoi fait quelque chose que le proxy perçoit comme inactif (pause de chiffrement, délai de réessai d'un fragment), le proxy coupe la connexion.

Diagnostiquez en envoyant hors du réseau d'entreprise (partage de connexion depuis votre téléphone). Si les timeouts disparaissent, le proxy est en cause. Demandez au service informatique d'autoriser le domaine du service de transfert et de contourner l'inspection pour ces domaines. L'alternative est d'utiliser un réseau personnel ou un tunnel VPN vers votre domicile.

TCP keepalive au niveau du système d'exploitation

Linux n'envoie les paquets TCP keepalive qu'après 2 heures d'inactivité par défaut, ce qui est inutile pour le transfert de fichiers. macOS et Windows ont des paramètres similaires. Pour les envois très longs sur des réseaux instables, certains services implémentent un keepalive au niveau applicatif via des pings WebSocket ou des fragments vides périodiques. Si le service ne le fait pas, les longs envois via un pare-feu NAT (timeout de session UDP de 5 minutes par défaut sur la plupart des routeurs domestiques) peuvent se casser quand l'entrée NAT expire.

Renouvellement du jeton de session VPN

Certains clients VPN renouvellent leur jeton de session toutes les 5 à 15 minutes. Sur les clients bogués, ce renouvellement coupe le tunnel TCP sous-jacent pendant une demi-seconde. Les longs envois meurent à ce moment-là.

Les VPN payants (Mullvad, ProtonVPN Plus, IVPN) gèrent cela proprement. Les VPN gratuits souvent non. Si vous constatez des timeouts systématiques autour de la marque des 10 minutes, suspectez le renouvellement VPN. Déconnectez le VPN pour l'envoi si le service de transfert utilise déjà le chiffrement de bout en bout TLS 1.3.

Bascules cellulaires

Les données mobiles changent de cellule à mesure que vous vous déplacez. Chaque bascule soit (a) conserve l'IP via la gestion de mobilité (transparente) soit (b) attribue une nouvelle IP (la connexion tombe). Sur LTE, la plupart des bascules sont transparentes. Sur 5G, notamment mmWave, les bascules vers sub-6 ou le repli LTE peuvent changer l'IP et tuer les connexions.

Si vous envoyez depuis un véhicule en mouvement sur données mobiles, attendez-vous à des coupures. Les outils d'envoi par fragments avec reprise gèrent bien cela ; les outils en flux unique non.

Timeouts mod_security et WAF

Si un service est protégé par un pare-feu applicatif web (Cloudflare WAF, AWS WAF, ModSecurity), le WAF peut signaler un envoi long comme suspect et le couper. Symptômes : les envois réussissent pour les petits fichiers, échouent à un seuil précis (souvent 1 Go ou 10 Go selon la configuration du WAF), avec des réponses 403 ou 502.

Rien à corriger côté client. Signalez-le au service. Un WAF bien configuré autorise les envois par fragments sans les signaler.

Timeouts du navigateur par défaut

Les navigateurs ont aussi des timeouts de requêtes, bien qu'ils soient généralement généreux pour les envois. Chrome et Firefox accordent un temps illimité aux requêtes XHR et fetch par défaut, mais ils coupent bien les connexions inactives après 5 minutes dans certaines configurations. Les Service Workers peuvent intercepter et prolonger les timeouts.

Si le JavaScript du service définit xhr.timeout = 30000 (30 secondes) par fragment, les fragments lents échouent. C'est un bug côté service ; signalez-le.

Antivirus inspectant le trafic HTTPS

Windows Defender avec l'inspection HTTPS activée, Norton, Bitdefender et similaires interceptent tous les connexions HTTPS pour analyser le contenu. Sur les gros envois, l'analyse elle-même ajoute une latence qui peut faire dépasser aux fragments les timeouts côté serveur.

Désactivez temporairement l'inspection HTTPS (pas l'antivirus complet, juste le scan HTTPS) pendant les grands envois. Si les envois réussissent, ajoutez le service de transfert à la liste d'exclusion de l'antivirus de façon permanente.

Logique de réessai et backoff exponentiel

Les clients de transfert bien construits réessaient les fragments échoués avec un backoff exponentiel : 1 seconde, puis 2, puis 4, puis 8. Un bref problème réseau se répare de façon transparente. Les clients sans logique de réessai échouent à la première erreur.

Si vous utilisez un service qui ne réessaie pas automatiquement, vous verrez davantage d'échecs causés par des timeouts. Choisissez un client ou un service qui gère les réessais pour vous.

Réessayez simplement après 15 minutes

Certains timeouts sont transitoires : un accroc sur un nœud Cloudflare, un déploiement de service, un lien de transit congestionné. Réessayez dans 15 minutes avant d'escalader. Si ça échoue à nouveau, passez sur un autre réseau pour isoler si le problème vient de vous ou d'eux.

Choisissez un service avec des réessais robustes

Pour les gros fichiers sur des réseaux peu fiables, vous voulez un service avec un réessai par fragment, un état de session reprenible, et aucun timeout serveur agressif. HexaTransfer exécute des envois par fragments en parallèle avec réessai par fragment et chiffrement AES-256-GCM côté client, de sorte qu'un envoi de 10 Go sur une connexion instable réessaie les fragments affectés de façon transparente plutôt que de faire échouer tout le transfert sur un seul accroc réseau.

Essayez sur hexatransfer.com — gratuit, sans compte, jusqu'à 10 Go.