2026 Petites équipes — Mac distant partagé : matrice Nginx vs Caddy pour l’entrée collaborative (TLS, latence, coût ops), au-delà de SSH/VNC

L’accès interactif reste couvert par le guide de choix SSH/VNC pour petites équipes, mais dès qu’une API interne, un webhook d’état de build ou une passerelle type OpenClaw doit être joignable depuis Internet, l’HTTP(S) devient une entrée à part entière. Sur un nœud mutualisé, trois classes de problèmes reviennent : certificats non renouvelés faute de propriétaire clair, empilement de connexions lorsque keepalives et pools upstream restent aux valeurs des tutoriels, et voisins bruyants lorsqu’un flux webhook monopolise les workers pendant qu’un autre développeur tient une session longue sur un tableau de bord. Croisez l’hygiène TLS avec la discipline bastion décrite dans la matrice Jump Host et rotation des certificats SSH : même calendrier opérationnel pour l’accès humain et machine.

1. Propriété floue du port 443 : double écoute, erreurs « address already in use » après reboot, jobs CI qui embarquent leur propre pile TLS.
2. Tables de workers et de connexions sous-dimensionnées : 502 intermittents quand plusieurs navigateurs s’attachent à la même passerelle pendant une release.
3. Journaux non structurés : impossible d’attribuer abus ou webhook mal configuré — douloureux pour l’audit lorsque plusieurs hôtes suivent un playbook webhook MeshMac et notification de build partagée.

Pourquoi ne pas s’en tenir au tunnel SSH ? Il reste pertinent pour l’administration, mais les clients web, les intégrations SaaS et les agents attendent du TLS standard, de l’ALPN et souvent du HTTP/2. Le reverse proxy devient donc la couche de décision entre « outil interne » et « surface exposée » — choix distinct de la simple exposition VNC, mais tout aussi sensible en gouvernance.

Utilisez ce tableau pour trancher la première bordure HTTPS sur un Mac loué. Les appréciations ciblent une équipe de cinq à vingt personnes sur un ou deux hôtes pool.

Synthèse décisionnelle : Caddy pour l’ACME rapide et une surface de config réduite ; Nginx pour le contrôle L7 maximal, le rate limiting éprouvé et l’alignement sur un parc existant. Dans les deux cas, un seul propriétaire du 443, des routes longues durée isolées des rafales webhook, et des journaux corrélables par request_id.

Base Nginx : upstream unique sur 127.0.0.1:8080, worker_processes auto, plafond initial worker_connections 4096 sur Mac Apple Silicon à charge modérée, keepalive 32 vers l’application, en-têtes compatibles WebSocket :

worker_processes auto;
events { worker_connections 4096; }
http {
  keepalive_timeout 65s;
  map $http_upgrade $connection_upgrade { default upgrade; '' close; }
  upstream app_local {
    server 127.0.0.1:8080;
    keepalive 32;
  }
  server {
    listen 443 ssl;
    http2 on;
    # ssl_certificate     /etc/letsencrypt/live/exemple/fullchain.pem;
    # ssl_certificate_key /etc/letsencrypt/live/exemple/privkey.pem;
    location / {
      proxy_http_version 1.1;
      proxy_set_header Host $host;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Forwarded-Proto $scheme;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection $connection_upgrade;
      proxy_read_timeout 3600s;
      proxy_send_timeout 3600s;
      proxy_pass http://app_local;
    }
  }
}

Équivalent Caddy : TLS automatique, HTTP/1.1 vers l’app, fenêtre keepalive transport (32s idle) et plafond 64 connexions idle :

exemple.meshmac.test {
  reverse_proxy 127.0.0.1:8080 {
    transport http {
      keepalive 32s
      keepalive_idle_conns 64
    }
    header_up Host {host}
    header_up X-Forwarded-For {remote_host}
    header_up X-Forwarded-Proto {scheme}
  }
}

• Workers : conserver worker_processes auto sur Apple Silicon tant que moins d’une dizaine d’utilisateurs lourds simultanés ; ne figer manuellement qu’après mesure de contention inter-cœurs.
• Keepalive amont : démarrer entre 16 et 64 connexions idle par groupe upstream ; monter si les journaux montrent des poignées de main TCP répétées coûteuses.
• Keepalive client : 65s pour keepalive_timeout (Nginx) sauf contraintes clients mobiles ou CDN frontal.
• Lectures longues : 3600s uniquement sur les routes qui streament réellement ; laisser ~60s ailleurs pour faire remonter vite un backend bloqué.

1. Installation : brew install nginx ou brew install caddy ; noter le service brew services / LaunchDaemon qui survit au reboot.
2. 443 exclusif : tout autre serveur de dev passe sur ports élevés ou sockets Unix ; consigner dans le runbook partagé du pool.
3. DNS et pare-feu : enregistrement vers l’hôte, TCP 443 ouvert côté fournisseur, émission ACME (Caddy ou certbot --nginx / webroot).
4. Pools upstream : appliquer les keepalive ci-dessus ; n’augmenter worker_connections qu’après kern.maxfiles et ulimit -n.
5. Journaux : inclure identifiant de requête, statut amont, version TLS pour corréler incidents webhook multi-utilisateurs.
6. Validation : curl -I https://exemple.meshmac.test, vérification ALPN, client WebSocket sur la route la plus longue.
7. Renouvellement : hook de reload pour Nginx (nginx -s reload) ; Caddy recharge souvent sans intervention.

Le port 443 est déjà pris sur notre Mac partagé : que faire ?

Identifier le PID avec sudo lsof -iTCP:443 -sTCP:LISTEN, fusionner sur un seul proxy, exposer les services secondaires par préfixes de chemin ou noms d’hôte supplémentaires dans la même SAN du certificat.

Comment séparer backends CI, dashboards et webhooks ?

Blocs upstream ou sites Caddy distincts, limites de débit différentes, route /hooks/ avec timeouts de lecture plus courts que la voie SSE/WebSocket interactive.

La terminaison TLS ajoute-t-elle une latence significative vs tunnel SSH ?

Sur boucle locale, TLS moderne reste sub-milliseconde par rapport aux dizaines de ms RTT géographique déjà payées ; le gain client est ALPN, HTTP/2 et reprise de session gérée proprement pour navigateurs et intégrations.

En résumé : choisissez l’outil qui minimise votre dette au moment où vous exposez une surface HTTPS sur un nœud mutualisé, pas celui qui brille en démo isolée. Documentez le propriétaire du 443, calibrez keepalive et timeouts par classe de trafic, et gardez des journaux exploitables pour les enquêtes post-incident — surtout lorsque plusieurs pipelines partagent le même Mac.