Pubblicare il sito ServBay su Internet (Reverse Proxy, Tunnel e Port Forwarding)

Oltre allo sviluppo in locale, molti utenti desiderano utilizzare ServBay su un server dedicato (come Mac mini in datacenter, workstation in ufficio, server Windows, ecc.) agendo da origin server, per poi esporre il sito al pubblico. Questo scenario è assolutamente realizzabile in produzione—molti utenti lo gestiscono con successo.

Tuttavia, senza una comprensione chiara del comportamento di rete predefinito di ServBay, è facile incappare in problemi legati a protocollo, certificati, intestazione Host o rete, che portano al classico: "locale tutto ok, accesso pubblico non funziona". Questa guida è pensata per chiunque desideri usare ServBay come origin server e illustra prima i comportamenti di default, quindi presenta le soluzioni complete in ordine: tunnel integrati → reverse proxy (consigliato) → port forwarding, seguite da una checklist di troubleshooting per le anomalie frequenti.

Piattaforme supportate

Questo articolo vale sia per ServBay su macOS sia per ServBay su Windows. La modalità dei protocolli web, il binding delle interfacce e il percorso dei certificati sono identici, cambia solo la directory di installazione (macOS: /Applications/ServBay; Windows: C:\ServBay). Il web server di default differisce: macOS usa Caddy, Windows usa Nginx, ma puoi sempre passare a Nginx/Apache/Caddy.

Comprendere il comportamento di rete predefinito di ServBay

La maggior parte dei problemi di accesso pubblico nascono dalla mancata conoscenza delle seguenti impostazioni di default:

Il sito utilizza di default HTTP & HTTPS. Con questa modalità, tutte le richieste HTTP (porta 80) vengono sempre reindirizzate via 301 su HTTPS (porta 443). È una scelta deliberatamente moderna: segui l'HTTPS, non tornare su 80 in chiaro.
La selezione di sito e certificato HTTPS avviene tramite SNI. Se ci sono più siti ServBay sullo stesso server, la selezione avviene tramite l'SNI durante l'handshake TLS (che corrisponde al dominio del sito). Un reverse proxy che effettua backend su HTTPS deve inviare il corretto SNI, altrimenti otterrai il sito/certificato di default.
Ascolto di default su tutte le interfacce (0.0.0.0), su porte 80 (HTTP) e 443 (HTTPS), il che permette di accedere anche dall'esterno senza modifiche.
Il certificato HTTPS locale è emesso dal CA interno di ServBay. ServBay integra una CA locale (appare come ServBay User CA - ECC Root), che genera i certificati del sito. I browser pubblici non la considerano affidabile—ma ti basta fidare questa CA (o saltare la verifica) sul reverse proxy, senza dover ottenere certificati pubblici per il traffico backend.

Errore tipico: HTTP & HTTPS + forwarding solo 80

Se lasci il sito in modalità HTTP & HTTPS ma fai forwarding solo sulla 80—senza gestire la 443—succede che il client richiede http://dominio → ServBay risponde con 301 https://dominio → il client cerca la 443 → non risponde nessuno → accesso fallito. Browser e HSTS cachano il 301, complicando la diagnosi.

La soluzione non è tornare a HTTP 80, ma configurare correttamente l’HTTPS (vedi la sezione reverse proxy).

Quale modalità di pubblicazione scegliere

Metodo	Descrizione	Scenari consigliati
Tunnel integrati (frpc / cloudflared, ecc.)	Integrato in ServBay, apre un tunnel verso l'esterno, senza richiedere IP pubblico o apertura porte	Mancanza di IP pubblico, rete casalinga/NAT, necessità di pubblicare in modo veloce
Reverse proxy frontale (consigliato)	Nginx/HAProxy/Caddy/Traefik ricevono il traffico pubblico, gestiscono i certificati e collegano via HTTPS al backend ServBay	Gateway pubblico, gestione unificata ingressi/multisito/certificati centralizzati
Port forwarding (NAT)	Le porte pubbliche vengono inoltrate direttamente verso ServBay	Un solo backend e piena consapevolezza della configurazione

Metodo 1: Tunnel integrati (il più semplice, senza IP pubblico)

Se non hai un IP pubblico o non vuoi occuparti di reverse proxy e certificati, i tunnel integrati di ServBay sono la soluzione più immediata. Instaurano connessioni dal tuo ServBay verso l'esterno, bypassando NAT, IPv6, port forwarding e problemi di fiducia del certificato:

Cloudflare Tunnel (cloudflared) — Esponi il sito locale via Cloudflare, fornisce automaticamente HTTPS pubblico e affidabile, senza aprire porte. Perfetto per dominio pubblico stabile + CDN/WAF.
frp (frpc) — Connessione a un tuo server frps, soluzione pienamente autonoma.
ngrok / Pinggy — Ottieni velocemente un URL pubblico temporaneo, adatto a demo, webhook e test.

Per molti, basta un tunnel cloudflared per “mettere online” il sito locale, senza necessità di approfondire proxy o port forwarding.

Metodo 2: Reverse Proxy frontale + HTTPS backend (Consigliato)

Questo è il setup raccomandato per la produzione: il reverse proxy gestisce HTTPS affidabile verso il pubblico, ma anche la comunicazione col backend ServBay avviene via HTTPS (lasciando il sito in modalità HTTP & HTTPS), per una sicurezza end-to-end.

Perché preferire l’HTTPS backend invece del solo HTTP 80

Molte guide online suggeriscono di mantenere HTTP tra proxy e backend. Noi non lo consigliamo, salvo casi molto particolari e ben compresi:

Cifratura end-to-end: anche in LAN, il traffico resta sicuro, evitando sniffing/man-in-the-middle.
Protocollo moderno: conservando HTTPS, la parte frontend può sfruttare HTTP/2 (h2) con tutti i vantaggi (multiplexing, compressione header, connessioni persistenti); su 80 rimani bloccato in paradigmi datati.
Niente trappole da downgrade: tornare a HTTP ti porta a combattere con redirect 301, HSTS, link https generati dalle app e simili.
Fidarsi del CA di ServBay è semplice: Non importa che sia auto-firmato—basta fidare la CA solo sul proxy o saltare la verifica; si configura una volta, dura nel tempo.

La soluzione HTTP 80 in chiaro è spiegata in Metodo 3 ed è solo per chi è consapevole dei rischi.

Punti chiave (validi per ogni reverse proxy)

Applicabili a tutti i reverse proxy; gli esempi considerano: dominio pubblico example.com, backend ServBay 192.168.1.115, porta backend HTTPS 443, sito ServBay in modalità HTTP & HTTPS.

Collegamento HTTPS backend: il proxy (proxy_pass/upstream) punta a https://192.168.1.115:443.
SNI corretto: L’SNI deve essere uguale al dominio ServBay (example.com), altrimenti ServBay non seleziona sito/certificato appropriato.
Fidare il CA di ServBay (consigliato) o saltare la verifica: vedi la sezione successiva.
Passaggio dell'header Host: Host: example.com per il server_name di ServBay.
Header X-Forwarded-Proto: https: Serve al backend per sapere che la richiesta era HTTPS, evitando link errati o redirect infiniti.
IPv4 / IPv6 coerenti: Vedi Coerenza IPv4/IPv6.

Recuperare il CA di ServBay (per fidare i certificati backend sul proxy)

I file del CA radice di ServBay si trovano all'interno della directory di installazione:

macOS: /Applications/ServBay/ssl/private/ServBay-Private-CA-ECC-Root.crt
Windows: C:\ServBay\ssl\private\ServBay-Private-CA-ECC-Root.crt (il percorso può variare)

Copia questo file .crt sul server del reverse proxy (ad es. /etc/nginx/servbay-ca/) e usalo come autorità affidata per la verifica backend.

Sulla catena dei certificati

ServBay usa una struttura "CA radice + CA intermedia", con i certificati dei siti firmati dalla CA intermedia. Se il proxy si fida solo della radice e la verifica fallisce, unisci la radice e quella intermedia (ServBay-Private-CA-ECC-Intermediate.crt) in un unico bundle CA; oppure, testa la connessione senza verifica, per poi tornare alla validazione formale.

Reverse proxy Nginx (HTTPS backend)

nginx

server {
    listen 443 ssl;
    listen [::]:443 ssl;                 # Per supporto IPv6
    server_name example.com;

    # Certificato pubblico per l’esterno (es: 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;                 # Backend HTTPS

        # —— Fondamentale: SNI e verifica backend ——
        proxy_ssl_server_name on;                             # Abilita invio SNI
        proxy_ssl_name        example.com;                    # SNI = dominio ServBay
        proxy_ssl_trusted_certificate /etc/nginx/servbay-ca/servbay-ca-bundle.crt;
        proxy_ssl_verify      on;                             # Verifica CA di ServBay
        proxy_ssl_verify_depth 2;                             # Due livelli (radice + intermedia)
        # Soluzione semplice (senza CA): proxy_ssl_verify off;

        # —— Fondamentale: passaggio Host e protocollo ——
        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;
    }
}

# HTTP redirect su HTTPS gestito dal proxy
server {
    listen 80;
    listen [::]:80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

Reverse proxy HAProxy (HTTPS backend)

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
    # Backend HTTPS: ssl + SNI + verifica 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
    # Soluzione semplice: server servbay1 192.168.1.115:443 ssl sni str(example.com) verify none

Reverse proxy Caddy (HTTPS backend)

Caddy chiederà e rinnoverà automaticamente il certificato pubblico per example.com. reverse_proxy passa già Host e X-Forwarded-* di default:

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
            # Soluzione semplice: tls_insecure_skip_verify
        }
    }
}

Reverse proxy Traefik (HTTPS backend)

Configurazione dinamica tramite provider file:

yaml

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

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

Metodo 3: Port forwarding (NAT)

Se gestisci un solo backend, puoi configurare sul gateway/router il port forwarding diretto verso la macchina ServBay (es: IP interno 192.168.1.115).

Consigliato: inoltra la 443, mantieni HTTPS

Port forwarding: porta pubblica 443 → 192.168.1.115:443 (e anche porta pubblica 80 → 192.168.1.115:80, lasciando poi a ServBay il redirect su 443).
DNS: il record A punta all’IPv4 pubblico.
Il sito resta in modalità HTTP & HTTPS. Dato che i visitatori pubblici si collegano direttamente a ServBay, dovrai impostare un certificato affidabile pubblico (consulta sotto), altrimenti riceverai warning sui browser.
Verifica della coerenza IPv4/IPv6 (vedi sotto).

Pubblicazione HTTP 80 in chiaro (solo per casi speciali)

Forwardare solo la 80 e cambiare la modalità del sito in HTTP ti fa perdere tutti i vantaggi di HTTPS e HTTP/2, ed è soggetto a conflitti con HSTS/cache browser. Raccomandato solo in casi estremi e consapevoli. Se decidi di farlo, cambia la modalità sito in HTTP (eviti il 301 su 443 non aperta) e forwarda solo la 80.

Coerenza IPv4 / IPv6

Uno dei motivi principali di instabilità. Se il dominio ha sia record A (IPv4) che AAAA (IPv6), il client userà spesso prioritariamente IPv6 (Happy Eyeballs). Se forward/proxy sono configurati solo per IPv4, parte delle richieste IPv6 fallirà. Due soluzioni:

Solo IPv4: assicurati che dig AAAA tuodominio +short non dia risultati, mantieni solo il record A.
Supporto IPv6: configura forwarding / proxy anche sulle interfacce IPv6 ([::]) e assicurati che anche il backend sia raggiungibile via IPv6.

Checklist troubleshooting anomalie di accesso

Se incontri problemi di accesso pubblico (sito non raggiungibile, timeout, errori certificato, sito sbagliato, ecc.) segui questi step, usando ad esempio il dominio example.com e backend 192.168.1.115:

Redirect 301 su 443 non inoltrato?
bash
```
curl -I http://example.com
```
1
Se ottieni 301 con Location: https://... e la 443 non è configurata → problema. Configura correttamente HTTPS (consigliato) o imposta il sito in modalità solo HTTP.

IPv6 sta interferendo?

bash

curl -4 -I https://example.com     # Solo IPv4
curl -6 -I https://example.com     # Solo IPv6
dig A example.com +short
dig AAAA example.com +short        # Se c’è AAAA ma IPv6 non funziona → rimuovi o configura correttamente

SNI/certificato backend corretti? (per HTTPS backend) Prova una richiesta diretta inviando l’SNI:
bash
```
curl -I --resolve example.com:443:192.168.1.115 https://example.com \
     --cacert /path/servbay-ca-bundle.crt
```
1
2
Se ricevi errori di certificato o sito non corrispondente, probabilmente SNI errato o CA non affidata.
La richiesta arriva a ServBay? Consulta i log del web server ServBay (tramite il menu "Visualizza Log"). Se le richieste in timeout non appaiono, il problema sta a livello network/gateway/proxy.
Header Host corretto? (per proxy L7)
bash
```
curl -k -I -H "Host: example.com" https://192.168.1.115/
```
1
Se backend funziona ma non dal proxy → il proxy non sta passando l’header Host.

Certificati e Sicurezza

Collegamento backend: da proxy a ServBay su HTTPS, configura il proxy per fidare il CA (ServBay-Private-CA-ECC-Root.crt, unisci CA intermedia se necessario). È una trust interna, basta configurarla una volta.
Certificato pubblico: per i visitatori pubblici serve un certificato affidabile. Se usi il reverse proxy, sarà lui a gestirlo (Caddy/Traefik lo rilasciano/gestiscono automaticamente); per accesso diretto, configura un certificato pubblico su ServBay (vedi Guida ACME all’emissione dei certificati). Il CA “ServBay User CA” è solo per accesso locale/LAN—i browser pubblici non si fidano.
Non esporre database e servizi: Quando pubblichi il web in Internet, non aprire anche MySQL, Redis, Memcached ecc.. Vedi Accesso LAN per i dettagli di sicurezza.
Firewall: concedi solo le porte strettamente necessarie, blocca tutto il resto.

FAQ - Domande frequenti

D: In locale funziona, su Internet no: è un problema DNS?
- R: Di solito no! Spesso il problema è il redirect 301 di HTTP & HTTPS verso la 443 non inoltrata, errata configurazione SNI/certificati, mancato passaggio dell’Host o incoerenza IPv4/IPv6. Segui la checklist.
D: Serve tornare a HTTP 80 per funzionare col proxy?
- R: Non serve, anzi è sconsigliato. Mantieni HTTP & HTTPS, il proxy deve collegarsi via HTTPS e fidare ServBay CA (o saltare verifica), così hai cifratura end-to-end e HTTP/2.
D: Errore certificato/sito backend dal proxy?
- R: Verifica che l’SNI sia quello corretto (dominio del sito), che la CA (inclusa la intermedia se serve) sia fidata. Per test puoi saltare la verifica, poi riattivarla.
D: ServBay su server in produzione è stabile?
- R: Certo. Molti utenti usano ServBay su Mac mini/server Windows in IDC come origin server stabile. L'importante è allineare protocollo, SNI, Host, CA e IPv4/IPv6.
D: Non ho IP pubblico, che faccio?
- R: Usa Metodo 1: Tunnel integrati (cloudflared/frpc), nessun bisogno di IP o port forwarding pubblico.

Conclusioni

Pubblicare ServBay come origin server su Internet è tecnicamente fattibile. La soluzione consigliata è mantenere il sito in modalità HTTP & HTTPS, adottare un reverse proxy che si collega via HTTPS backend, inviando SNI corretto e fidando la CA di ServBay, così ottieni cifratura end-to-end, HTTP/2 e le tecnologie più moderne; se non hai IP pubblico, i tunnel cloudflared/frpc integrati sono la strada più pratica; il port forwarding diretto va bene solo se sei perfettamente consapevole dei rischi. In caso di problemi, segui la checklist: quasi sempre è una questione di protocollo, SNI/certificati, Host o IPv4/IPv6.

Pubblicare il sito ServBay su Internet (Reverse Proxy, Tunnel e Port Forwarding) ​

Comprendere il comportamento di rete predefinito di ServBay ​

Quale modalità di pubblicazione scegliere ​

Metodo 1: Tunnel integrati (il più semplice, senza IP pubblico) ​

Metodo 2: Reverse Proxy frontale + HTTPS backend (Consigliato) ​

Perché preferire l’HTTPS backend invece del solo HTTP 80 ​

Punti chiave (validi per ogni reverse proxy) ​

Recuperare il CA di ServBay (per fidare i certificati backend sul proxy) ​

Reverse proxy Nginx (HTTPS backend) ​

Reverse proxy HAProxy (HTTPS backend) ​

Reverse proxy Caddy (HTTPS backend) ​

Reverse proxy Traefik (HTTPS backend) ​

Metodo 3: Port forwarding (NAT) ​

Coerenza IPv4 / IPv6 ​

Checklist troubleshooting anomalie di accesso ​

Certificati e Sicurezza ​

FAQ - Domande frequenti ​

Conclusioni ​