2026 : perte de paquets, gigue MTR et blocages SSH intermittents vers un Mac mini ProxyMac quand le ping reste « vert »
Les ingénieurs qui louent des mini Apple Silicon M4 à Hong Kong, au Japon, en Corée, à Singapour ou aux États-Unis collent souvent une capture ping à 28 ms de RTT moyenne tout en jurant que SSH « se fige dix secondes sans raison ». Ce paradoxe cache en général perte de paquets ou gigue derrière une moyenne ICMP trop aimable. Cet article donne (1) le vocabulaire qui sépare perte et latence, (2) les colonnes MTR qui collent aux shells interactifs, (3) une matrice en cinq lignes pour localiser les pertes, (4) un runbook en sept étapes avant un ticket de migration, (5) des critères honnêtes pour changer entre HK / JP / KR / SG / US. À lire avec diagnostic MTR/traceroute, bufferbloat Wi‑Fi si le premier saut bruite, et keepalive TCP une fois le chemin stable.
Pourquoi la perte de paquets n’est pas « juste la RTT » vers un Mac mini cloud
Le ping lisse le temps aller-retour ; il ne garantit pas que chaque segment TCP portant des frappes arrive dans une fenêtre prévisible. Un chemin à 1,2 % de perte aléatoire peut garder un ping poli pendant qu’OpenSSH attend des retransmissions—surtout avec canaux multiplexés ou fenêtres scp rétrécies. La gigue amplifie : si la RTT oscille entre 32 ms et 210 ms sur cinq secondes, la perception humaine parle de « pics » même si la moyenne reste jolie.
En revue, citez la dispersion, pas seulement la moyenne : deux chemins à même moyenne peuvent rendre tmux et Vim complètement différents si la queue est lourde. L’objectif est d’ancrer le débat régional dans des mesures.
- Chiffres utiles : une perte soutenue ≥2 % sur les trois derniers sauts colle souvent aux blocages SSH visibles ; sous 1 % peut encore faire mal au-delà de 250 ms RTT car les timers de retransmission dominent.
- Indice débit : un flux SCP unique peut plafonner à 4–7 MB/s sur du Wi‑Fi 200 Mbps « propre » si la perte est là—loin sous les tableaux PHY.
- Indice idle : les sessions qui meurent après 12–18 minutes de silence pointent souvent vers des middleboxes NAT ; gardez ces tickets séparés.
ping -c 200 sur macOS), noter la moyenne et l’écart-type ; au-delà de 8 ms sur un court trajet urbain, enchaînez avec MTR.
Colonnes MTR qui prédisent vraiment la douleur SSH
MTR fusionne traceroute et sondes continues pour montrer la perte par saut. Lisez Loss%, StDev et Wrst ensemble—jamais un saut isolé. Beaucoup de routeurs backbone limitent volontairement ICMP : faux « 100 % » au milieu alors que le dernier saut reste propre. Si SSH et MTR divergent, faites confiance au comportement applicatif et à la stabilité du saut final.
Sur macOS, installez MTR via Homebrew (brew install mtr) et exécutez-le avec les droits raw sockets. Capturez au moins 300 cycles pendant l’incident puis hors heures ; si la perte disparaît la nuit, suspectez la congestion plutôt qu’un composant mort. Si ICMP est interdit, corrélez les horodatages ssh -vvv aux compteurs de votre point d’accès Wi‑Fi.
Archivez les journaux bruts : la finance aime les preuves datées pour arbitrer les budgets région. Ajoutez cinq métadonnées : FAI source, ville, VPN oui/non, hostname exact, test sur Ethernet ou non.
Matrice en cinq lignes : localiser la perte avant d’accuser Tokyo ou Singapour
| Schéma | Où vit souvent la perte | Premier geste |
|---|---|---|
| Sauts 1–2 instables, reste propre | Wi‑Fi ou tampon CPE | Test Ethernet A/B, largeur de canal, article bufferbloat |
| Perte seulement avec VPN | Concentrateur d’entreprise ou split tunnel | Tunnel complet vs liste d’exclusion ; guide Zero Trust |
| Spikes en heures ouvrées au milieu | Congestion peering/transit | Ticket avec MTR ; trois fenêtres propres avant move |
| Dernier saut bruyant, milieu nickel | Bordure destination ou NIC hôte | Capture côté fournisseur ; rotation du port SSH |
| Perte corrélée aux gros uploads | Saturation asymétrique | Limiter les transferts parallèles, scp -l |
Cette grille transforme les intuitions carte-pin en langage partagé pour l’astreinte et les nouvelles recrues.
Runbook en sept étapes : du ressenti à la preuve
- Ping baseline avec stats : au moins 200 sondes, min/avg/max/écart-type, perte séparée de la RTT.
- MTR vers le même endpoint SSH (nom ou IP), 300+ cycles pendant la fenêtre de panne.
- Répéter sur Ethernet à moins de 2 m de l’AP si Wi‑Fi ; si Ethernet guérit la perte, arrêt—aucune région ne répare une mauvaise airtime.
- Basculer les profils VPN et voir si la perte suit l’interface tunnel (
utun). - Instrumenter SSH :
ssh -vvvet bloquer les blocages sur messages « pledge: network » ou retrans TCP. - Hygiène transport : quand la perte tombe sous ~0,5 %, ajouter
ServerAliveInterval 30etTCP_USER_TIMEOUTnoyau comme dans le guide keepalive. - Décision région : seulement si trois fenêtres ouvrées propres montrent la perte sur les sauts finaux et que le fournisseur confirme l’absence de maintenance locale—puis comparer latence inter-régionale.
Quand changer entre HK / JP / KR / SG / US aide vraiment
Changer de région est un choix de coût mensuel. Ça aide quand les diagnostics montrent à plusieurs reprises congestion ou peering sur un metro précis—souvent quand votre FAI amont route de façon asymétrique vers APAC. Ça n’aide pas si le saut 1 perd déjà 4 % : vous traînez la première mile cassée partout. Traitez la migration comme une expérience contrôlée : snapshots des builds, durées git fetch, débit VNC avant/après ; visez 48 heures de métriques propres.
Quand le marketing veut être « plus proche clients », traduisez en RTT et perte mesurées. Les empreintes disponibles sont sur la page tarifs ; pour justifier avec des chiffres, croisez avec les checklists d’accès distant du centre d’aide.
FAQ
Le partage d’écran UDP prouve-t-il la perte plus vite que SSH ? Parfois l’UDP tolère différemment ; le signal faible reste MTR vers le port TCP dont vous dépendez.
Faut-il activer tous les flags TCP fast-open ? Pas tant que le chemin est sale ; les sysctl exotiques perdent rarement contre Wi‑Fi ou VPN.
ICMP bloqué mais SSH OK ? Fiez-vous à l’application ; sans MTR, compteurs d’interface et boucles scp temporisées.
Pourquoi un Mac mini ProxyMac gagne encore une fois le chemin clarifié
Quand la perte retombe sous le pour cent, un Mac mini M4 dédié offre un macOS prévisible pour Xcode, outillage notarisé et automatisation alignée sur le portable—sans racheter du métal tous les 36 mois. La mémoire unifiée Apple Silicon tient de longues sessions SSH à côté d’agents sans surprises de surbooking VM. Comparez les offres sur la page tarifs, gardez VNC pour les secours GUI, et rangez ce playbook à côté du mémo MTR pour transformer le prochain « blocage aléatoire » en diagnostic de quelques minutes.
Mesurez le chemin, puis louez la région
HK / JP / KR / SG / US · Apple Silicon M4