ServBay website publiceren naar het publieke internet (Reverse proxy, tunnels & port forwarding)

Naast lokale ontwikkeling kiezen veel gebruikers ervoor om ServBay te installeren op een server die permanent draait (bijvoorbeeld een Mac mini in een datacenter, een vaste kantoor-pc of Windows-server), en deze als backend origin server te gebruiken. De website wordt vervolgens online aangeboden aan het publiek. Dit is in productie prima mogelijk—veel gebruikers draaien op deze manier probleemloos.

Maar wie de standaard netwerkwerking van ServBay niet kent, maakt makkelijk fouten met protocol, certificaten, host headers of netwerkconfiguratie, en belandt in de “lokaal werkt alles, van buiten niet” val. Dit artikel legt eerst deze standaardgedragingen uit, en biedt dan een complete aanpak in de volgorde Ingebouwde tunnels → Reverse proxy (aanbevolen) → Port forwarding, gevolgd door een handige checklist voor probleemoplossing bij toegangsfouten.

Geschikt voor platformen

Dit artikel is van toepassing op ServBay voor macOS én ServBay voor Windows. Op beide platformen zijn de protocolmodi, luisterlijnen en certificaatpaden identiek; alleen de installatielocatie verschilt (macOS: /Applications/ServBay, Windows meestal C:\ServBay; controleer je installatie). De standaard webserver verschilt: macOS gebruikt standaard Caddy, Windows standaard Nginx — beide kunnen wisselen naar Nginx / Apache / Caddy.

Eerst: standaard netwerkgedrag van ServBay

Veel problemen rondom publieke toegang ontstaan uit misverstanden over deze basis:

De standaard website-modus is HTTP & HTTPS. HTTP (poort 80) requests worden altijd 301 geredirect naar HTTPS (poort 443). Dit is bewust: het is veiliger en moderner om HTTPS te volgen. Herleid daarom de verbinding niet terug naar HTTP.
HTTPS kiest site & certificaat via SNI. Op één ServBay host kunnen meerdere sites draaien. Aan de hand van SNI (TLS Server Name Indication, gelijk aan je domeinnaam) kiest ServBay het juiste certificaat en virtuele host. Reverse proxies die via HTTPS verbinding maken, móeten de juiste SNI meesturen, anders krijg je het standaardcertificaat/-site.
De server luistert standaard op alle netwerkinterfaces (0.0.0.0), met poorten 80 (HTTP) en 443 (HTTPS), en is van buiten toegankelijk. Gewoonlijk hoef je het bind-adres niet aan te passen.
Lokale HTTPS-certificaten worden ondertekend door de ServBay CA. ServBay heeft een ingebouwde lokale CA (ServBay User CA - ECC Root in je certificaatbeheer), en ondertekent daar je site-certificaten mee. Bezoekers zullen dit lokaal niet vertrouwen—maar je hoeft alleen de reverse proxy deze CA te laten vertrouwen (of verificatie uit te schakelen) en géén publiekscertificaat aan te vragen voor de backend.

Typisch probleem: HTTP & HTTPS + alleen poort 80 doorsturen

Laat je de standaard HTTP & HTTPS-modus aan, maar stuur je alleen poort 80 door, niet ook 443: client vraagt http://domeinnaam → ServBay geeft een 301 https://domeinnaam → client probeert 443 → geen server luistert → foutmelding. Browsers en HSTS kunnen deze 301 zelfs cachen, waardoor oplossen langer duurt.

De juiste oplossing is niet teruggaan naar HTTP, maar HTTPS correct laten werken (zie het reverse proxy-advies hieronder).

Welke publicatiemethode kiezen?

Methode	Uitleg	Geschikte situaties
Ingebouwde tunnels (frpc / cloudflared, etc.)	Meegeleverd in ServBay, maakt actief externe tunnels, geen publiek IP of poorten nodig	Geen publiek IP, thuis/NAT-netwerk, snel online willen
Reverse proxy vóór ServBay (aanbevolen)	Nginx/HAProxy/Caddy/Traefik ontvangt publiek verkeer en certificaten, proxy’t via HTTPS	Publieke instappunt beschikbaar, centrale toegang/scaling nodig
Port forwarding (NAT)	Gateway stuurt poorten direct door naar ServBay host	Eén backend, je weet wat je doet

Methode 1: Ingebouwde tunnel (eenvoudig, geen publiek IP nodig)

Heb je geen publiek IP, of wil je niet rommelen met proxies en certificaten, dan is de ingebouwde tunnelservice van ServBay het handigst. Deze maken actief verbinding naar buiten, en omzeilen vanzelf NAT, IPv6, port forwarding en certificaatvertrouwen:

Cloudflare Tunnel (cloudflared) — Biedt je lokale site aan via Cloudflare wereldwijd, met automatisch geldig HTTPS voor het publiek; je hoeft geen poorten open te zetten. Ideaal als je een stabiele domeinnaam + CDN / WAF wilt.
frp (frpc) — Verbindt naar je eigen frps-server, volledige controle.
ngrok / Pinggy — Snel een tijdelijke publieke URL maken, geschikt voor demo’s en externe webhooks.

Voor velen is cloudflared voldoende om “lokaal online brengen” af te dekken; je hoeft de overige proxy/port forwarding-mogelijkheden niet te lezen.

Methode 2: Reverse proxy vóór ServBay + HTTPS backend (aanbevolen)

In productie is dit het advies: de proxy biedt extern bestaand HTTPS aan, en maakt ook intern via HTTPS verbinding met ServBay (laat de site dus gewoon HTTP & HTTPS draaien), voor end-to-end encryptie.

Waarom via HTTPS proxy’en naar de backend, en niet gewoon HTTP?

Veel tutorials sturen het proxyverkeer naar backend via HTTP. Dat raden wij af, behalve in zeldzame situaties waarin je de gevolgen kent:

End-to-end encryptie: Zelfs in private netwerken wordt dan alles versleuteld, geen sniffing of manipulatie mogelijk.
Moderne protocolfeatures: Alleen met HTTPS (niet HTTP) kan de frontend probleemloos HTTP/2 (h2) gebruiken (voor multiplexing, header compressie, enz.); HTTP-lockt je vast in oude technologie.
Voorkom moeilijke (debug-)problemen: Ga je terug naar HTTP, dan krijg je te maken met 301-redirects, HSTS, HTTP-links in applicaties en meer.
De ServBay CA vertrouwen is simpel: Zelf-gesigneerde ServBay CA is geen probleem—laat de proxy die CA vertrouwen, of schakel verificatie uit, en je bent klaar.

Zie Methode 3 voor onbeveiligd HTTP. Alleen aan te raden bij volledige kennis van de consequenties.

Algemeen belangrijk

De volgende tips gelden voor alle vier de proxies. Voorbeelden gebruiken domein example.com, backend 192.168.1.115, backend HTTPS poort 443, en ServBay site op HTTP & HTTPS.

Proxy via HTTPS: Proxy-instelling / upstream = https://192.168.1.115:443
Stuur correcte SNI: SNI moet exact de domeinnaam zijn zoals op je ServBay-site geconfigureerd (example.com). Anders krijg je een fout/incorrect certificaat.
Vertrouw ServBay CA (aanbevolen), of sla validatie over: Zie de volgende paragraaf voor waar het CA-certificaat te vinden.
Host-header transparant doorgegeven: Host: example.com, zodat ServBay de juiste virtual host kiest.
Stuur X-Forwarded-Proto: https: Hiermee herkent de backend HTTPS-verzoeken en worden er geen HTTP-links teruggegeven of redirect-loops veroorzaakt.
Match IPv4 / IPv6: Zie Consistente IPv4/IPv6.

ServBay CA vinden (voor proxy-vertrouwen)

Het lokale root CA-certificaat van ServBay staat in de installatiemap:

macOS: /Applications/ServBay/ssl/private/ServBay-Private-CA-ECC-Root.crt
Windows: C:\ServBay\ssl\private\ServBay-Private-CA-ECC-Root.crt (controleer je installatiepad)

Kopieer deze .crt naar de server waar je reverse proxy draait (bijvoorbeeld /etc/nginx/servbay-ca/), en wijs die aan als trusted CA in je proxyconfiguratie.

Over certificate chains

ServBay gebruikt een tweelaags structuur: root CA + intermediate CA. De website-certificaten worden via de intermediate ondertekend. Gaat validatie in de proxy fout en vertrouw je alleen de root, voeg dan de intermediate (ServBay-Private-CA-ECC-Intermediate.crt in dezelfde map) samen met de root tot een CA-bundle. Of gebruik eerst “skip-verificatie” om te testen, en zet later strenge validatie aan.

Nginx, reverse proxy (HTTPS backend)

nginx

server {
    listen 443 ssl;
    listen [::]:443 ssl;                 # Voor IPv6 support
    server_name example.com;

    # Extern publiek vertrouwd certificaat, bijv. 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;                 # Proxy via HTTPS

        # —— Belangrijk: SNI & certificaat validatie ——
        proxy_ssl_server_name on;                             # SNI meesturen
        proxy_ssl_name        example.com;                    # SNI = domeinnaam ServBay site
        proxy_ssl_trusted_certificate /etc/nginx/servbay-ca/servbay-ca-bundle.crt;
        proxy_ssl_verify      on;                             # Certificaat controleren
        proxy_ssl_verify_depth 2;                             # Root + intermediate
        # Eenvoudige optie (niet checken): proxy_ssl_verify off;

        # —— Belangrijk: Host & protocol header ——
        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 naar HTTPS doorsturen door de proxy
server {
    listen 80;
    listen [::]:80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

HAProxy, reverse proxy (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
    # HTTPS backend: ssl + SNI + cert-verificatie
    server servbay1 192.168.1.115:443 ssl sni str(example.com) \
        verify required ca-file /etc/haproxy/servbay-ca/servbay-ca-bundle.crt
    # Eenvoudig: server servbay1 192.168.1.115:443 ssl sni str(example.com) verify none

Caddy, reverse proxy (HTTPS backend)

Caddy vraagt automatisch geldige certificaten aan voor example.com. reverse_proxy stuurt standaard Host en X-Forwarded-* headers door:

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

Traefik, reverse proxy (HTTPS backend)

Voorbeeld dynamische 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                 # Host header doorsturen
        servers:
          - url: "https://192.168.1.115:443" # Proxy over HTTPS
        serversTransport: servbay-tls

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

Methode drie: Port forwarding (NAT)

Met slechts één backend kan de gateway/router publiek verkeer direct doorsturen naar de ServBay host (bijv. interne IP 192.168.1.115).

Advies: stuur 443 door, behoud HTTPS

Port forwarding op de router: publiek 443 → 192.168.1.115:443 (en eventueel 80 → 192.168.1.115:80 zodat ServBay zelf 80 naar 443 kan redirecten).
DNS: A-record instellen voor je domeinnaam naar het externe IP.
Laat de site op HTTP & HTTPS staan. Omdat publiek direct verbinding maakt, moet ServBay voor deze domeinnaam een geldig publiek certificaat hebben (zie certificaat-uitleg verderop), anders krijgen bezoekers browserwaarschuwingen.
Zorg voor consistente IPv4 / IPv6-instelling (zie volgend hoofdstuk).

Onbeveiligd HTTP 80 (enkel voor uitzonderingsgevallen)

Alleen poort 80 doorsturen en de site in HTTP zetten schakelt alle voordelen van HTTPS en HTTP/2 uit, en veroorzaakt snel problemen met browser HSTS/caching. Doe dit alleen als je de consequenties volledig begrijpt. Zet in dat geval het siteprotocol expliciet op HTTP (om 301’s te voorkomen) en stuur alleen poort 80 door.

IPv4 / IPv6 consistentie

Toegankelijkheidsproblemen zijn vaak terug te voeren op een mismatch tussen IPv4 en IPv6. Heeft een domein zowel een A (IPv4) als een AAAA (IPv6) record, dan geeft de browser soms voorrang aan IPv6 (Happy Eyeballs). Heb je alleen IPv4 doorgestuurd/proxyed, faalt het deel verkeer dat IPv6 probeert. Oplossing:

Alleen IPv4 gebruiken: Check dat dig AAAA jouwdomein +short leeg is, gebruik enkel een A-record.
Beide ondersteunen: Regel port forwarding/proxying voor IPv6 (luister op [::]), en zorg dat de backend via IPv6 bereikbaar is.

Checklist: Probleemoplossing publieke toegang

Werkt publieke toegang niet (time-outs, foutmeldingen, verkeerde certificaten, verkeerde site)? Ga dit stapsgewijs na (voorbeeld met domein example.com en backend 192.168.1.115):

Wordt alles 301-geredirect naar een ongeopende poort 443?
bash
```
curl -I http://example.com
```
1
Zie je een 301 met Location: https://..., maar luister je niet op 443? Dit is het probleem. Schakel HTTPS in (aanbevolen), of zet de site op HTTP.

Probleem met IPv6?

bash

curl -4 -I https://example.com     # Forceer IPv4
curl -6 -I https://example.com     # Forceer IPv6
dig A example.com +short
dig AAAA example.com +short        # Heb je een AAAA-record, maar is IPv6 niet goed ingesteld? Verwijder deze, of maak IPv6 werkend.

Klopt SNI/certificaat bij backend-proxy (HTTPS)? Test handmatig een SNI-verzoek:
bash
```
curl -I --resolve example.com:443:192.168.1.115 https://example.com \
     --cacert /path/servbay-ca-bundle.crt
```
1
2
Melding over verkeerd certificaat/wrong site? Waarschijnlijk stuurt de proxy geen SNI of vertrouwt de CA niet.
Komt het verzoek wel bij ServBay aan? Bekijk access logs van de betreffende ServBay-website (Menu "Bekijk Log-bestanden"). Zie je de time-out niet terug, zit het probleem in netwerk/gateway/proxy.
Klopt de Host-header? (L7 proxy)
bash
```
curl -k -I -H "Host: example.com" https://192.168.1.115/
```
1
Werkt rechtstreekse backend-toegang goed, maar via proxy niet? Dan wordt de Host-header niet correct doorgegeven.

Certificaten & beveiliging

Backend-verbinding: Laat de proxy het ServBay CA-certificaat (ServBay-Private-CA-ECC-Root.crt, eventueel gebundeld met intermediate CA) vertrouwen. Deze stap is voor intern gebruik & langdurig geldig.
Publieke certificaten: Voor bezoekers heb je publiek vertrouwde certificaten nodig. Bij gebruik van een proxy regelt deze vaak de certificaten (Caddy/Traefik kunnen ze automatisch aanvragen); Bij port forwarding moet je ServBay instrueren een publiek certificaat te gebruiken, bijvoorbeeld via ACME-certificaat aanvragen. Het ServBay self-signed ServBay User CA-certificaat is uitsluitend bedoeld voor lokaal/LAN — internetbezoekers vertrouwen dit niet.
Stel je database niet open naar het internet! Zet alleen de webdienst open. Laat MySQL, Redis, Memcached, enz. niet van buitenaf toegankelijk zijn. Zie LAN-toegang voor beveiligingstips.
Firewall: Open enkel noodzakelijke poorten, de rest blokkeren.

Veelgestelde vragen (FAQ)

Q: Lokaal werkt alles, maar extern niet — is dit DNS?
- A: In de meeste gevallen niet (“geen DNS-resolutie”), maar ligt het aan een 301 van HTTP & HTTPS naar niet-geopende 443, verkeerde SNI/certificaat, missende Host-header, of een IPv4/IPv6 mismatch. Check de checklist hierboven.
Q: Moet ik altijd terug naar HTTP 80 voor proxy’s?
- A: Nee, en dat raden wij af. Houd de site op HTTP & HTTPS, proxy via HTTPS en vertrouw de ServBay CA (of schakel validatie tijdelijk uit) — dan heb je end-to-end encryptie + HTTP/2.
Q: Proxy’s geven SSL/certificaatfouten, of verkeerde site?
- A: Controleer of de juiste SNI gestuurd wordt (domeinnaam van de site) én of de proxy het ServBay CA-certificaat vertrouwt (eventueel incl. intermediates). Test eventueel eerst zonder verificatie.
Q: Is ServBay geschikt als productie-origin op een server?
- A: Ja. Veel gebruikers draaien ServBay op een (Mac mini of Windows-server) in een datacenter, 24/7 online. Stem protocolmodus, SNI, Host-header, certificaatvertrouwen & IPv4/IPv6 goed af.
Q: Wat als ik geen publiek IP heb?
- A: Gebruik Methode 1: Ingebouwde tunnel (cloudflared / frpc), dus geen port forwarding nodig.

Samenvatting

ServBay als backend origin online brengen is absoluut werkbaar. Aanbevolen aanpak: houd je site in HTTP & HTTPS modus, gebruik een reverse proxy die via HTTPS naar ServBay verbindt, stuur correcte SNI + vertrouw de ServBay CA — dan krijg je end-to-end encryptie + HTTP/2. Heb je geen publiek IP, dan is cloudflared/frpc-tunnel het makkelijkst. Port forwarding hoort alleen bij als je de risico's en details begrijpt. Bij problemen helpt de troubleshooting-checklist: issues zitten vrijwel altijd in protocol, SNI/certificaat, Host-header of IPv4/IPv6.

ServBay website publiceren naar het publieke internet (Reverse proxy, tunnels & port forwarding) ​

Eerst: standaard netwerkgedrag van ServBay ​

Welke publicatiemethode kiezen? ​

Methode 1: Ingebouwde tunnel (eenvoudig, geen publiek IP nodig) ​

Methode 2: Reverse proxy vóór ServBay + HTTPS backend (aanbevolen) ​

Waarom via HTTPS proxy’en naar de backend, en niet gewoon HTTP? ​

Algemeen belangrijk ​

ServBay CA vinden (voor proxy-vertrouwen) ​

Nginx, reverse proxy (HTTPS backend) ​

HAProxy, reverse proxy (HTTPS backend) ​

Caddy, reverse proxy (HTTPS backend) ​

Traefik, reverse proxy (HTTPS backend) ​

Methode drie: Port forwarding (NAT) ​

IPv4 / IPv6 consistentie ​

Checklist: Probleemoplossing publieke toegang ​

Certificaten & beveiliging ​

Veelgestelde vragen (FAQ) ​

Samenvatting ​