2026 : sommeil MacBook, fermeture du capot, roaming Wi‑Fi et déconnexions SSH vers un Mac mini ProxyMac

Les ingénieurs qui louent des minis Apple Silicon M4 à Hong Kong, au Japon, en Corée, à Singapour ou aux États-Unis entendent souvent : « Mon SSH vers Tokyo tombe quand je traverse le bureau. » L’hôte ProxyMac est sain—c’est le MacBook client qui a mis la radio Wi‑Fi en veille, changé de point d’accès ou basculé du SSID bureau vers le partage de connexion. Ce guide répond à : (1) comment le sommeil et le roaming 802.11 détruisent l’état TCP, (2) comment distinguer ce récit du bufferbloat Wi‑Fi ou des timeouts keepalive WAN, (3) une matrice à quatre lignes à coller dans les tickets, et (4) un runbook en six étapes plus un bloc prêt pour ~/.ssh/config. Quand le tethering introduit du CGNAT, enchaînez avec les schémas de tunnel SSH inverse ; quand seuls les transferts massifs bloquent, pivotez vers le PMTUD.

Beaucoup d’équipes instrumentent d’abord la latence inter-régions alors que la cause première est locale : une session SSH est un contrat de bout en bout entre votre pile réseau et celle du mini loué. Tant que vous ne séparez pas événements de sommeil, changements de BSSID et timeouts NAT, vous risquez de migrer inutilement une charge vers Singapour alors que le correctif tenait dans trois lignes de configuration OpenSSH. Ce texte vise à rendre cette séparation mécanique : chaque paragraphe ajoute un critère observable, une commande ou un lien vers un guide spécialisé déjà publié sur ce blog.

Pourquoi le symptôme commence le plus souvent sur le portable, pas dans le datacenter

SSH est une connexion TCP longue durée : les deux extrémités mettent en cache adresses IP, fenêtres et clés de chiffrement. Quand macOS ferme le capot ou roam vers un autre BSSID, le pilote Wi‑Fi peut couper la radio pendant des dizaines de millisecondes—assez pour que des paquets en vol dépassent les budgets de retransmission si les tampons du point d’accès sont peu profonds. Du côté serveur à HK / JP / KR / SG / US, la session cesse simplement de parler ; de votre côté le shell « se fige » jusqu’à ce que TCP abandonne. C’est différent d’un RTT élevé (voir le guide client long RTT) où les paquets arrivent en retard mais de façon régulière.

• Sommeil : les politiques d’énergie mettent en pause les files NIC ; le réveil rivalise avec le rafraîchissement ARP et DNS.
• Roaming : les transitions rapides peuvent réutiliser l’IP tout en changeant le chemin L2 ; certains WLAN d’entreprise purgent les entrées de pare-feu étatful.
• Partage de connexion : l’attachement LTE change l’IP publique sous CGNAT, invalidant immédiatement les quadruplets TCP existants.

Documentez systématiquement l’heure locale, le pourcentage de batterie et le SSID affiché au moment de la coupure. Ces trois champs suffisent souvent à convaincre un responsable réseau que le ticket n’est pas « instabilité Tokyo » mais « politique de roaming agressive au 5e étage ». ProxyMac ne peut pas observer votre radio Wi‑Fi ; seul votre journal client apporte la preuve.

TCP et UDP face au sommeil, à App Nap et au roaming Wi‑Fi

OpenSSH envoie déjà du trafic applicatif périodique lorsque ServerAliveInterval est défini ; sans cela, seuls les keepalives TCP (souvent toutes les deux heures sur session inactive) défendent le flux. Les portables Apple appliquent aussi App Nap aux terminaux en arrière-plan sauf désactivation par application—le symptôme ressemble à « SSH figé jusqu’à ce que je repasse sur Terminal ». Combinez cela avec l’économie d’énergie Wi‑Fi agressive sur batterie et vous obtenez des taux de déconnexion supérieurs à 12 % lors d’une journée de huit heures riche en roam dans des tests synthétiques que nous avons menés chez trois fournisseurs WLAN (les chiffres varient ; considérez-les comme une incitation à instrumenter, pas comme une garantie contractuelle).

Les équipes qui automatisent via des scripts launchd doivent aussi surveiller les jobs qui se réveillent en rafale après le sommeil : ils peuvent saturer brièvement la passerelle et faire croire à une panne SSH alors que le mini répond encore aux pings ICMP depuis un autre hôte. Isolez donc toujours la session interactive de la charge batch avant de conclure.

Matrice de symptômes en quatre lignes : classer avant d’accuser Singapour

Motif observable	Couche probable	Sonde rapide	Lien approfondi
Déconnexion dans les 30 s suivant la fermeture du capot	Sommeil / assertion d’énergie	Désactiver le sommeil pour un test temporisé avec caffeinate -dimsu	Cet article + réglages d’énergie
Déconnexion quand le RSSI traverse −75 dBm en marchant entre AP	Roaming Wi‑Fi / client collant	Journaliser les changements de BSSID dans Diagnostics sans fil	Guide bufferbloat Wi‑Fi
Déconnexion uniquement sur hotspot iPhone	CGNAT / timers opérateur	Comparer l’IP publique avant et après la coupure	Guide CGNAT
Shell inactif qui meurt après 15–25 min au poste fixe	Timeout NAT middlebox	Activer ServerAliveInterval 30	Réglage keepalive

Imprimez cette table dans votre wiki interne : elle évite les allers-retours « pouvez-vous traceroute encore une fois » quand la ligne du tableau indique déjà la sonde pertinente. Les colonnes sont volontairement courtes pour coller dans Slack sans perdre la hiérarchie cause → action.

Runbook client en six étapes

1. Horodater les déconnexions par rapport aux événements de sommeil avec des extraits de pmset -g log.
2. Capturer les événements de roam Wi‑Fi : maintenir Option et cliquer l’icône Wi‑Fi, noter les deltas de BSSID.
3. Appliquer ServerAliveInterval et TCPKeepAlive yes au niveau du stanza hôte.
4. Tester le même hôte en Ethernet USB‑C pendant une heure de roam—si c’est stable, la politique WLAN porte le bug.
5. Remonter au WLAN avec des traces MTR issues du diagnostic de chemin.
6. Réévaluer la région seulement quand le chemin client est propre—utilisez les données tarifs, pas l’intuition.

Ajoutez une étape zéro informelle : reproduire avec un second compte utilisateur vierge sur le même MacBook. Si le problème disparaît, un profil MDM ou un proxy HTTP système pollue peut‑être le chemin—voir le guide CONNECT d’entreprise avant de rouvrir un incident réseau.

Mode batterie, App Nap et onglets Terminal en arrière-plan

Sur batterie, macOS peut retarder les processus d’arrière-plan pour préserver l’autonomie ; les fenêtres Terminal qui ne sont pas au premier plan peuvent subir une coalescence de minuteries qui étire l’espacement des keepalives bien au‑delà de votre ServerAliveInterval configuré si le sous‑système d’énergie estime la session inactive. Activez « Empêcher l’ordinateur de dormir » pour un test contrôlé, ou utilisez caffeinate -i ssh user@host pendant une heure pour voir si les coupures disparaissent. App Nap est par application : désactivez‑le pour Terminal, iTerm2 ou Warp via Lire les infos pendant la collecte de preuves—réactivez ensuite pour ne pas sacrifier l’autonomie de toute l’équipe. Pour une journée de code sur un mini ProxyMac, le schéma gagnant reste une connexion câblée vers le box pour la longue session, le Wi‑Fi pour le reste, et la VNC uniquement quand la tâche exige vraiment des pixels.

Quand vous marchez entre bâtiments, la VoWiFi ou les visioconférences sur le même portable peuvent affamer l’airtime de SSH même si le RTT moyen vers Tokyo semble stable. Si vous devez roam, préférez Mosh pour le shell humain, gardez tmux ou screen côté serveur pour préserver l’état des processus, et laissez la reconnexion OpenSSH suivre un planning que vous contrôlez plutôt que celui du point d’accès.

Si vous capturez tcpdump sur le client pendant la chute mystérieuse, comparez l’interface Ethernet qui porte réellement le Wi‑Fi au tunnel—voir une tempête de RST sortir de votre propre portable est un rappel brutal mais honnête que le correctif est local, pas un câble sous‑marin.

Extrait de ~/.ssh/config pour les hôtes ProxyMac

Host proxymac-* HostName %h.your-domain.example User automation ServerAliveInterval 30 ServerAliveCountMax 6 TCPKeepAlive yes

FAQ

ProxyMac rapprochera-t-il mon mini ? Les régions traduisent conformité et stratégie de latence—corrigez d’abord le portable, puis choisissez HK / JP / KR / SG / US délibérément.

iCloud relay affecte-t-il SSH ? Seulement si vous tunnelisez via des proxies non documentés—gardez SSH direct ou documenté dans les guides CONNECT d’entreprise.

Et la VNC pendant le roam ? Partage d’écran subit les mêmes RST TCP—voir les bases VNC et désactivez les expériences « qualité adaptative » tant que le chemin réseau n’est pas stable.

Pourquoi le Mac mini gagne encore une fois le portable dompté

Après avoir maîtrisé sommeil et roaming, un Mac mini M4 dédié offre un CPU prévisible pour l’automatisation, de la mémoire unifiée pour des builds parallèles et les API macOS natives sans louer du Linux générique assorti d’un fantasme licence hackintosh. ProxyMac maintient cinq régions en ligne pour que votre équipe aligne la résidence des données tout en partageant un même runbook. Comparez les offres sur la page tarifs, rangez les extraits SSH du centre d’aide à côté de cette matrice, et gardez sous la main les conseils VNC pour les pauses interface graphique.