Publier un site ServBay sur Internet (proxy inverse, tunnel & redirection de port)

Au-delà du développement local, de nombreux utilisateurs déploient ServBay sur un serveur permanent (Mac mini en datacenter, poste bureautique fixe, serveur Windows, etc.) comme serveur d'origine pour mettre leur site en ligne sur Internet. C’est une pratique tout à fait viable en production — de nombreux utilisateurs l’exécutent ainsi avec succès.

Cependant, une mauvaise compréhension du comportement réseau par défaut de ServBay peut mener à divers pièges (protocole, certificats, en-tête Host, réseau), ce qui donne « tout va bien en local, mais accès public problématique ». Ce guide s’adresse à tous ceux qui veulent utiliser ServBay en tant que serveur d’origine, et vous permettra de comprendre ces comportements par défaut avant de détailler les solutions dans l'ordre Tunnel intégré → Proxy inverse (recommandé) → Redirection de port, suivi d’une checklist de dépannage.

Plateformes concernées

Cet article concerne ServBay pour macOS et ServBay pour Windows. Les deux plateformes ont le même fonctionnement concernant les protocoles, les ports écoutés et les chemins des certificats (seul le dossier d’installation diffère : /Applications/ServBay sous macOS, C:\ServBay sous Windows). Le serveur web par défaut diffère : Caddy pour macOS, Nginx pour Windows, mais vous pouvez basculer entre Nginx / Apache / Caddy.

Comprendre d'abord le comportement réseau de base de ServBay

La majorité des soucis d’accès depuis Internet viennent de confusions sur ces points-clés :

Le site est en HTTP & HTTPS par défaut. Dans ce mode, toute requête HTTP (80) reçoit un 301 sans condition vers HTTPS (443). Ce choix moderne est voulu : utilisez donc HTTPS, évitez de revenir au HTTP en clair.
Le HTTPS sélectionne le site et le certificat via le SNI. Sur une même instance ServBay avec plusieurs sites, le SNI (soit le nom de domaine) est utilisé dans la poignée de main TLS pour cibler le bon site et le bon certificat. Le proxy inverse doit transmettre le bon SNI en retour HTTPS, sinon vous obtiendrez le site/certificat par défaut.
Écoute sur toutes les interfaces réseau par défaut (0.0.0.0) sur les ports HTTP 80 / HTTPS 443, donc accessible de l’extérieur sans avoir à modifier l’adresse de binding.
Le certificat HTTPS local est signé par ServBay CA. ServBay embarque une autorité de certification locale (ServBay User CA - ECC Root dans le trousseau) qui signe les certificats pour vos sites. Les navigateurs publics ne la reconnaissent pas — mais il suffit d’ajouter cette CA de ServBay comme autorité de confiance sur le proxy inverse (ou de désactiver la vérification). Il n'est pas nécessaire de demander un certificat public uniquement pour le lien retour.

Piège classique : HTTP & HTTPS + rediriger seulement le port 80

Si vous gardez HTTP & HTTPS et que vous ne redirigez que le port 80 sans traiter le 443 : le client demande http://domaine → ServBay renvoie 301 https://domaine → le client tente le 443 → aucune réponse → accès échoué. Le navigateur/HSTS gardera en cache ce 301, ce qui complique encore le diagnostic.

Ne repassez pas en HTTP : faites fonctionner correctement le HTTPS (voir la solution proxy inverse ci-dessous).

Comparatif des trois méthodes de publication

Méthode	Description	Pour quel usage
Tunnel intégré (frpc/cloudflared)	Fourni avec ServBay, établit un tunnel sortant, pas besoin d’IP publique ni d’ouvrir les ports	Pas d’IP publique, réseau familial/NAT, publication rapide
Proxy inverse frontal (recommandé)	Nginx/HAProxy/Caddy/Traefik reçoivent le trafic public, gèrent les certificats, et retournent en HTTPS	Entrée publique, mutualisation, certificats centraux
Redirection de ports (NAT)	Routeur/NAT transfert directement le port public vers ServBay	Un seul backend, utilisateur averti

Méthode 1 : Tunnel intégré (le plus simple, sans IP publique)

Si vous n’avez pas d’IP publique ou que vous voulez éviter de configurer un proxy ou les certificats, le tunnel intégré de ServBay est la solution la plus simple, car il établit une connexion sortante et évite tous les problèmes liés au NAT, à l’IPv6, aux ouvertures de port et à la confiance des certificats :

Cloudflare Tunnel (cloudflared) — Expose votre site local via le réseau mondial de Cloudflare, avec un HTTPS public et fiable automatiquement, sans ouvrir de port. Idéal pour un domaine public + CDN/WAF fiable.
frp (frpc) — Relie à votre propre serveur frps, pour un contrôle total.
ngrok / Pinggy — Génère un lien public temporaire, parfait pour des démonstrations ou du test de webhook.

Pour la majorité des utilisateurs, un tunnel cloudflared suffit pour « exposer un site local sur Internet » — inutile d’aller plus loin (proxy ou redirection de port).

Méthode 2 : Proxy inverse frontal + retour HTTPS (recommandé)

C’est la méthode préconisée en production : le proxy frontal offre un HTTPS public de confiance, et retourne vers ServBay en HTTPS (conservant le mode HTTP & HTTPS), afin d’assurer un chiffrement de bout en bout.

Pourquoi privilégier le retour en HTTPS plutôt qu’en HTTP

La plupart des tutoriels se contentent du schéma classique « le backend reste en HTTP, le proxy inverse fait un retour non chiffré ». Nous déconseillons cette ancienne méthode, sauf cas très particuliers, car :

Chiffrement bout-en-bout : Même en interne, toutes les communications proxy <-> ServBay sont chiffrées, évitant le sniffing ou l'altération du trafic.
Technologies modernes : Conserver le HTTPS permet d’activer facilement HTTP/2 (h2) côté frontal et de profiter de la multiplexion, compression d’en-têtes, etc. HTTP 80 vous cantonne aux anciens protocoles.
Éviter les pièges liés à la rétrogradation : Revenir à HTTP vous expose à quantité de soucis : 301 dû au mode HTTP & HTTPS, cache HSTS du navigateur, génération de liens https...
Faire confiance à la CA ServBay est trivial : La CA étant auto-signée, il suffit de l’ajouter comme autorité de confiance côté proxy (ou de désactiver la vérification), ce qui reste fiable dans la durée.

Pour le pur HTTP 80, voir Méthode 3 — réservé aux utilisateurs expérimentés.

Points universels

Ces points s’appliquent à tous les exemples de proxy cités ci-dessous, avec le nom de domaine example.com, le serveur ServBay en 192.168.1.115, port HTTPS 443, et site en mode HTTP & HTTPS.

Retour en HTTPS : le proxy doit utiliser proxy_pass / upstream en https://192.168.1.115:443.
Envoyer le bon SNI : le SNI doit correspondre au domaine configuré sur ServBay (example.com), sinon le bon certificat/site ne sera pas trouvé.
Faire confiance à la CA ServBay (recommandé) ou désactiver la vérification : voir la section suivante pour récupérer le fichier CA.
Transmettre l’en-tête Host : Host: example.com pour que ServBay fasse la bonne correspondance.
Passer X-Forwarded-Proto: https : pour que l’application backend sache que la requête d’origine était en https (évite des redirects, des liens http générés, etc.).
Uniformité IPv4/IPv6 : voir Cohérence IPv4/IPv6.

Récupérer la CA ServBay (pour la confiance du proxy inverse)

Le certificat racine de la CA ServBay se trouve dans le dossier d’installation :

macOS : /Applications/ServBay/ssl/private/ServBay-Private-CA-ECC-Root.crt
Windows : C:\ServBay\ssl\private\ServBay-Private-CA-ECC-Root.crt (adapter au chemin d’installation)

Copiez ce fichier .crt sur le serveur proxy (ex. /etc/nginx/servbay-ca/) et déclarez-le comme autorité de confiance pour la validation du retour HTTPS.

À propos de la chaîne de certificats

ServBay utilise une structure « racine + intermédiaire ». Si la confiance sur la seule racine ne suffit pas, fusionnez la racine et l’intermédiaire (dans le même dossier, ex. ServBay-Private-CA-ECC-Intermediate.crt) en un bundle à déclarer dans les proxy. Sinon, commencez par désactiver la vérification, puis passez à la validation stricte dès que possible.

Proxy inverse Nginx (retour HTTPS)

nginx

server {
    listen 443 ssl;
    listen [::]:443 ssl;                 # Pour supporter IPv6
    server_name example.com;

    # Certificat public de confiance (ex : Let's Encrypt)
    ssl_certificate     /etc/nginx/certs/example.com/fullchain.pem;
    ssl_certificate_key /etc/nginx/certs/example.com/privkey.pem;

    location / {
        proxy_pass https://192.168.1.115:443;                 # Retour en HTTPS

        # —— Important : SNI & confiance ——
        proxy_ssl_server_name on;                             # Envoyer SNI
        proxy_ssl_name        example.com;                    # SNI = nom de domaine du site ServBay
        proxy_ssl_trusted_certificate /etc/nginx/servbay-ca/servbay-ca-bundle.crt;
        proxy_ssl_verify      on;                             # Activer vérification après ajout CA ServBay
        proxy_ssl_verify_depth 2;                             # Racine + intermédiaire
        # Mode simple (sans CA) : proxy_ssl_verify off;

        # —— Important : transmission Host & proto ——
        proxy_set_header Host              $host;
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

# Passage automatique du HTTP vers HTTPS par le proxy
server {
    listen 80;
    listen [::]:80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

Proxy inverse HAProxy (retour HTTPS)

haproxy

frontend fe_web
    bind :80
    bind :443 ssl crt /etc/haproxy/certs/example.com.pem
    http-request redirect scheme https unless { ssl_fc }
    http-request set-header X-Forwarded-Proto https if { ssl_fc }
    default_backend be_servbay

backend be_servbay
    option forwardfor
    http-request set-header Host example.com
    # Retour HTTPS : ssl + SNI + confiance CA ServBay
    server servbay1 192.168.1.115:443 ssl sni str(example.com) \
        verify required ca-file /etc/haproxy/servbay-ca/servbay-ca-bundle.crt
    # Version simple : server servbay1 192.168.1.115:443 ssl sni str(example.com) verify none

Proxy inverse Caddy (retour HTTPS)

Caddy gère automatiquement l’obtention et le renouvellement du certificat public ; reverse_proxy transmet par défaut l’en-tête Host et les X-Forwarded-* :

caddy

example.com {
    reverse_proxy https://192.168.1.115:443 {
        header_up Host {host}
        transport http {
            tls_server_name example.com                                  # SNI
            tls_trusted_ca_certs /etc/caddy/servbay-ca/servbay-ca-bundle.crt
            # Option simple : tls_insecure_skip_verify
        }
    }
}

Proxy inverse Traefik (retour HTTPS)

Exemple avec configuration dynamique file provider :

yaml

# traefik-dynamic.yml
http:
  routers:
    servbay:
      rule: "Host(`example.com`)"
      entryPoints:
        - websecure
      service: servbay
      tls:
        certResolver: letsencrypt
  services:
    servbay:
      loadBalancer:
        passHostHeader: true                 # Transmettre Host
        servers:
          - url: "https://192.168.1.115:443" # Retour HTTPS
        serversTransport: servbay-tls

serversTransports:
  servbay-tls:
    serverName: example.com                  # SNI
    rootCAs:
      - /etc/traefik/servbay-ca/servbay-ca-bundle.crt
    # Option simple : insecureSkipVerify: true

Méthode 3 : Redirection de port (NAT)

Si vous n’avez qu’un seul backend, vous pouvez directement rediriger le port public sur la box/routeur vers la machine ServBay (ici, IP locale 192.168.1.115).

Recommandé : rediriger le 443, conserver le HTTPS

Établir la redirection : port public 443 → 192.168.1.115:443 (et port public 80 → 192.168.1.115:80 pour laisser ServBay faire la redirection 80→443).
Configurer l’enregistrement DNS A pour pointer sur l’IP publique.
Laisser le site en HTTP & HTTPS. Comme les visiteurs se connectent directement à ServBay, il faut un certificat public de confiance pour ce domaine (voir la section certificats), sinon ils auront un avertissement.
Vérifier la cohérence IPv4/IPv6.

Envoi direct en clair sur HTTP 80 (cas extrême)

Utiliser seulement le port 80 avec un site en mode HTTP fera perdre tous les avantages de HTTPS/HTTP2, et peut causer des soucis avec le cache/HSTS du navigateur. Strictement réservé aux cas exceptionnels avec utilisateurs avertis. Si besoin, basculez explicitement le site en mode HTTP (pour éviter le 301 intempestif vers 443), et ne redirigez que le port 80.

Cohérence IPv4/IPv6

Cause fréquente d’instabilité d’accès. Si votre domaine a à la fois une entrée A (IPv4) et une AAAA (IPv6), les clients peuvent parfois privilégier IPv6 (Happy Eyeballs) ; si vous ne redirigez que pour IPv4, les requêtes IPv6 échoueront. Deux choix :

Utiliser uniquement IPv4 : Vérifiez que dig AAAA votredomaine +short ne retourne rien, gardez uniquement l’entrée A.
Supporter IPv6 partout : Ajoutez les redirections/configs IPv6 et vérifiez l’accès du backend en v6.

Checklist de dépannage en cas d’accès anormal

En cas de problème d’accès (erreur, timeout, certificat, mauvais site...), vérifiez point par point (exemple : domaine example.com, backend 192.168.1.115) :

Redirigé en 301 vers un 443 non ouvert ?
bash
```
curl -I http://example.com
```
1
Si retour 301 avec Location: https://..., mais rien n’écoute sur 443 → c’est le souci. Configurez le HTTPS ou passez le site en mode HTTP uniquement.

Problème lié à l’IPv6 ?

bash

curl -4 -I https://example.com     # Forcer IPv4
curl -6 -I https://example.com     # Forcer IPv6
dig A example.com +short
dig AAAA example.com +short        # Si AAAA existe mais IPv6 ne répond pas → supprimez ou corrigez

SNI/certificat correct pour le retour ? (cas retour HTTPS) Test direct auprès du backend :
bash
```
curl -I --resolve example.com:443:192.168.1.115 https://example.com \
     --cacert /path/servbay-ca-bundle.crt
```
1
2
Si erreur de correspondance certificat/site, le SNI est sûrement faux ou la CA non déclarée.
Les requêtes atteignent-elles ServBay ? Sur la machine ServBay, vérifiez les logs d’accès Web. Si rien quand vous faites un test, c’est que la requête bloque sur le réseau, le NAT ou le proxy.
L’en-tête Host est-il correct ? (cas proxy L7)
bash
```
curl -k -I -H "Host: example.com" https://192.168.1.115/
```
1
Si accès direct OK mais pas via le proxy : votre proxy ne transmet pas l’en-tête Host.

Certificats & sécurité

Lien retour proxy → ServBay : Passez en HTTPS, et faites confiance à la CA ServBay (ServBay-Private-CA-ECC-Root.crt ; fusionnez avec l’intermédiaire si besoin). Ce n’est requis qu’en interne, une seule configuration suffit.
Certificat public : Le certificat vu depuis Internet doit être officiel/public. En mode proxy inverse, c’est le proxy (Caddy / Traefik...) qui gère — il peut même l’obtenir/renouveler automatiquement ; en mode redirection de port, c’est à vous de le configurer dans ServBay (voir Demander un certificat ACME). Le certificat auto-signé ServBay n’est valable qu’en LAN/local — jamais sur le Net public.
Ne pas exposer la base de données : En rendant le web accessible, n’exposez jamais MySQL/Redis/Memcached. Voir Accès LAN côté sécurité.
Pare-feu : Ouvrez uniquement les ports nécessaires, tout le reste doit être bloqué.

FAQ

Q : Tout fonctionne en local, accès public impossible, souci DNS ?
- R : Ce n’est presque jamais un souci de résolution, mais typiquement : 301 dû au mode HTTP & HTTPS pointant vers un 443 non traité, SNI/certificat absent, entête Host mal transmis ou incohérence IPv4/IPv6. Vérifiez chaque étape de la checklist.
Q : Faut-il absolument repasser en HTTP 80 pour faire fonctionner le proxy inverse ?
- R : Non, et c’est déconseillé ! Gardez HTTP & HTTPS, faites le retour proxy en HTTPS avec confiance dans la CA ServBay (ou désactivez la vérification), vous gardez le chiffrement bout-en-bout ET HTTP/2.
Q : Erreur de certificat ou mauvais site en retour proxy ?
- R : Vérifiez l'émission du bon SNI (= nom de domaine), que la CA ServBay (et les intermédiaires si besoin) sont déclarés côté proxy. Pour tester, commencez avec la vérification désactivée, puis passez à strict.
Q : ServBay est-il fiable comme serveur de production ?
- R : Oui ! Beaucoup d’utilisateurs exploitent ServBay sur Mac mini / Windows en datacenter avec stabilité. Veillez seulement à la cohérence du mode de protocole, SNI, Host, confiance de certificat et IPV4/IPv6.
Q : Pas d’IP publique, comment faire ?
- R : Utilisez Méthode 1 : Tunnel intégré (cloudflared/frpc), pas besoin d’IP ni de redirection.

Conclusion

Faire de ServBay un serveur d’origine exposé sur Internet est tout à fait faisable. La solution recommandée : restez en mode HTTP & HTTPS, utilisez un proxy frontal qui retourne le trafic en HTTPS en fixant le bon SNI et en faisant confiance à la CA ServBay, ce qui vous permet de bénéficier du chiffrement bout-en-bout et de HTTP/2. Si vous n’avez pas d’IP publique, le tunnel intégré cloudflared / frpc est le plus pratique. La redirection de port reste réservée aux utilisateurs avertis. En cas d’anomalie, la checklist ci-dessus permet un diagnostic rapide : le problème vient presque toujours du protocole, du SNI/certificat, de l’entête Host ou d’un souci IPv4/IPv6.

Publier un site ServBay sur Internet (proxy inverse, tunnel & redirection de port) ​

Comprendre d'abord le comportement réseau de base de ServBay ​

Comparatif des trois méthodes de publication ​

Méthode 1 : Tunnel intégré (le plus simple, sans IP publique) ​

Méthode 2 : Proxy inverse frontal + retour HTTPS (recommandé) ​

Pourquoi privilégier le retour en HTTPS plutôt qu’en HTTP ​

Points universels ​

Récupérer la CA ServBay (pour la confiance du proxy inverse) ​

Proxy inverse Nginx (retour HTTPS) ​

Proxy inverse HAProxy (retour HTTPS) ​

Proxy inverse Caddy (retour HTTPS) ​

Proxy inverse Traefik (retour HTTPS) ​

Méthode 3 : Redirection de port (NAT) ​

Cohérence IPv4/IPv6 ​

Checklist de dépannage en cas d’accès anormal ​

Certificats & sécurité ​

FAQ ​

Conclusion ​