Publikacja strony ServBay do internetu (reverse proxy, tunelowanie i przekierowanie portów)

Poza lokalnym rozwojem, wielu użytkowników wdraża ServBay na stale działającym serwerze (np. Mac mini w kolokacji, komputer biurowy, serwer Windows), używając go jako serwer źródłowy (origin server), a następnie udostępnia stronę internetową w publicznej sieci. Jest to podejście w pełni produkcyjne — wielu użytkowników stosuje je stabilnie od dłuższego czasu.

Jeśli jednak nie zrozumiesz domyślnego zachowania sieciowego ServBay, łatwo występują problemy z protokołami, certyfikatami, nagłówkiem Host czy kwestiami sieciowymi, skutkujące sytuacją „lokalnie działa, a z internetu nie”. Ten artykuł, skierowany do wszystkich planujących użycie ServBay jako backendu, najpierw wyjaśnia domyślne zachowanie, następnie przedstawia pełne rozwiązania w kolejności: wbudowane tunele → reverse proxy (zalecane) → przekierowanie portów, a na końcu zawiera ogólną listę kontrolną do analizy problemów z dostępem.

Obsługiwane systemy

Niniejszy przewodnik dotyczy zarówno ServBay na macOS, jak i ServBay na Windows. Tryby protokołów, zachowanie nasłuchu i ścieżki do certyfikatów są identyczne, różni się jedynie domyślny katalog instalacji (/Applications/ServBay na macOS, zwykle C:\ServBay na Windows). Domyślny serwer www: Caddy na macOS, Nginx na Windows — oba można przełączyć na Nginx / Apache / Caddy.

Zrozum domyślne zachowanie sieciowe ServBay

Większość problemów z dostępnością wynika z braku świadomości dotyczącej poniższych ustawień:

Domyślny tryb strony to HTTP & HTTPS. W tym trybie każde wejście na HTTP (port 80) jest bezwzględnie przekierowywane 301 na HTTPS (443). To nowoczesna, intencjonalna wartość domyślna — powinieneś korzystać z HTTPS, nie wracaj do nieszyfrowanego 80.
HTTPS wybiera stronę i certyfikat na podstawie SNI. Na tym samym ServBay kilka stron jest rozpoznawanych po SNI (czyli nazwie domeny) w handshake TLS. Reverse proxy musi wysyłać poprawne SNI podczas połączenia po HTTPS — inaczej otrzymasz domyślną stronę i certyfikat.
Domyślnie nasłuch na wszystkich interfejsach (0.0.0.0), porty HTTP 80 / HTTPS 443 są otwarte na zewnątrz, zwykle nie trzeba modyfikować adresu wiązania.
Lokalny certyfikat HTTPS podpisany przez ServBay CA. ServBay zawiera lokalne CA (w pęku kluczy jako ServBay User CA - ECC Root), które podpisuje certyfikaty dla Twoich stron. Przeglądarki internetowe odwiedzających nie ufają temu CA — wystarczy dodać zaufanie lub pominąć weryfikację na reverse proxy, nie trzeba wydawać publicznych certyfikatów dla połączenia zwrotnego.

Typowy błąd: HTTP & HTTPS + tylko przekierowanie portu 80

Jeśli zostawisz domyślny tryb HTTP & HTTPS i przekierujesz tylko port 80, a nie 443: klient żąda http://domena → ServBay odpowiada 301 https://domena → klient łączy się na 443 → nikt nie odpowiada → błąd połączenia. Przeglądarki i HSTS zapamiętają to przekierowanie, utrudniając diagnostykę.

Prawidłowo nie wracaj do HTTP 80, a skonfiguruj poprawny ruch HTTPS (patrz sekcja o reverse proxy poniżej).

Trzy metody publikacji — która wybrać?

Metoda	Opis	Zastosowanie
Wbudowane tunele (frpc / cloudflared itd.)	Gotowe w ServBay — serwer sam nawiązuje tunel, nie potrzebujesz publicznego IP czy otwartych portów	Nie masz publicznego IP, sieci domowe/NAT, chcesz szybko udostępnić
Reverse proxy (zalecane)	Nginx/HAProxy/Caddy/Traefik odbiera ruch z internetu i zarządza certyfikatami, dalej po HTTPS do ServBay	Masz punkt wejścia w internecie, potrzebujesz jednolitego wejścia / kilku backendów / centralnego certyfikatu
Przekierowanie portów (NAT)	Router przekierowuje porty publiczne bezpośrednio na ServBay	Jeden backend i pełna świadomość konsekwencji ustawień

Metoda 1: Wbudowane tunele (najprostsze, bez publicznego IP)

Gdy nie masz publicznego IP lub nie chcesz zaprzątać sobie głowy reverse proxy i certyfikatami, wbudowany system tunelowania ServBay jest najprostszym rozwiązaniem. Serwer nawiązuje połączenie na zewnątrz, omijając naturalnie NAT, IPv6, przekierowania portów oraz kwestię zaufania do certyfikatów:

Cloudflare Tunnel (cloudflared) — udostępnia lokalną stronę w internecie przez globalną sieć Cloudflare, zapewnia publiczny, zaufany HTTPS bez otwierania portów. Idealne jeśli chcesz stabilny adres + CDN/WAF.
frp (frpc) — łączy się do własnego serwera frps, pełna kontrola.
ngrok / Pinggy — błyskawiczne generowanie tymczasowych URL, dobre na demo czy testy webhooków.

W przypadku większości użytkowników tunel przez cloudflared całkowicie wystarcza, by „wystawić lokalną stronę do internetu”; kolejne sekcje o reverse proxy czy przekierowaniu portów możesz wtedy pominąć.

Metoda 2: Reverse proxy + HTTPS powrót (zalecane)

To rekomendowany sposób do środowisk produkcyjnych: reverse proxy udostępnia publiczny, zaufany HTTPS, a połączenie zwrotne do ServBay również pozostaje HTTPS (trzymaj tryb HTTP & HTTPS na stronie) — masz wtedy szyfrowanie end-to-end.

Dlaczego HTTPS powrotny, a nie HTTP 80?

W sieci krążą poradniki, gdzie backend działa na HTTP, a proxy przekazuje ruch bez szyfrowania. Nie rekomendujemy (chyba że doskonale rozumiesz ryzyko):

Szyfrowanie end-to-end: nawet w sieci LAN ruch jest cały czas szyfrowany, nie da się go podsłuchać ani modyfikować.
Współczesne możliwości protokołów: tylko HTTPS pozwoli uruchomić HTTP/2 w frontendzie i uzyskać korzyści wydajności (multipleksacja, kompresja nagłówków, reuse połączeń); HTTP 80 zamyka te opcje.
Unikasz typowych błędów degradacyjnych: powrót do HTTP generuje masę problemów — przekierowania 301, cachowanie HSTS, linki „https” w aplikacji itd.
Zaufanie do CA jest bardzo proste: wystarczy raz skonfigurować na reverse proxy, żeby ufało CA ServBay lub pomijało weryfikację — i problem znika na lata.

Sposób z HTTP 80 omówiony w Metodzie 3 — tylko dla w pełni świadomych.

Kluczowe punkty dla wszystkich reverse proxy

Wszystkie poniższe zalecenia dotyczą Nginx, HAProxy, Caddy, Traefik. Przykład: domena publiczna example.com, backend ServBay 192.168.1.115, port HTTPS backendu 443, tryb strony to HTTP & HTTPS.

Powrót po HTTPS: proxy_pass / upstream kieruje na https://192.168.1.115:443.
Wysłanie poprawnego SNI: SNI musi być domeną skonfigurowaną w ServBay (example.com) — w innym wypadku nie dostaniesz właściwej strony ani certyfikatu.
Zaufać CA ServBay (zalecane) lub pominąć weryfikację: patrz następna sekcja o pobraniu CA.
Przesyłaj nagłówek Host: Host: example.com — ServBay rozpozna stronę po server_name.
Ustaw X-Forwarded-Proto: https: backend dowie się, że wejście było przez https, co zapobiega problemom z generacją linków http/redirect loop.
Spójność IPv4 / IPv6: patrz Spójność IPv4/IPv6.

Pozyskanie ServBay CA dla reverse proxy

Certyfikat root CA znajduje się w katalogu instalacyjnym ServBay:

macOS: /Applications/ServBay/ssl/private/ServBay-Private-CA-ECC-Root.crt
Windows: C:\ServBay\ssl\private\ServBay-Private-CA-ECC-Root.crt (może się różnić zależnie od instalacji)

Skopiuj plik .crt na serwer reverse proxy (np. /etc/nginx/servbay-ca/) i wskaż jako zaufane CA dla połączeń do backendu.

O łańcuchu certyfikatów

ServBay korzysta ze struktury CA z root + intermediate. Jeśli reverse proxy ufa tylko root i weryfikacja się nie udaje, połącz root i intermediate (ServBay-Private-CA-ECC-Intermediate.crt w tym samym katalogu) do jednego pliku CA bundle i użyj w proxy; możesz też na czas testów wyłączyć weryfikację, a później ją zaostrzyć.

Reverse proxy Nginx (HTTPS powrót)

nginx

server {
    listen 443 ssl;
    listen [::]:443 ssl;                 # Dla obsługi IPv6
    server_name example.com;

    # Publiczny certyfikat (np. 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;                 # HTTPS powrót

        # —— Kluczowy: SNI i weryfikacja CA ——
        proxy_ssl_server_name on;                             # Wysyłaj SNI
        proxy_ssl_name        example.com;                    # SNI = domena w ServBay
        proxy_ssl_trusted_certificate /etc/nginx/servbay-ca/servbay-ca-bundle.crt;
        proxy_ssl_verify      on;                             # Wymuś weryfikację CA po zaufaniu
        proxy_ssl_verify_depth 2;                             # Root + intermediate
        # Prościej (brak CA): proxy_ssl_verify off;

        # —— Przesyłaj Host i protokół ——
        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;
    }
}

# Przekierowanie HTTP -> HTTPS (w proxy)
server {
    listen 80;
    listen [::]:80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

Reverse proxy HAProxy (HTTPS powrót)

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
    # Powrót po HTTPS: ssl + SNI + weryfikacja CA
    server servbay1 192.168.1.115:443 ssl sni str(example.com) \
        verify required ca-file /etc/haproxy/servbay-ca/servbay-ca-bundle.crt
    # Prościej: server servbay1 192.168.1.115:443 ssl sni str(example.com) verify none

Reverse proxy Caddy (HTTPS powrót)

Caddy sam odbiera i odnawia publiczny certyfikat na example.com, a reverse_proxy domyślnie przekazuje Host i 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
            # Prościej: tls_insecure_skip_verify
        }
    }
}

Reverse proxy Traefik (HTTPS powrót)

Przykład pliku dynamicznej konfiguracji (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                 # Przekazuj Host
        servers:
          - url: "https://192.168.1.115:443" # HTTPS powrót
        serversTransport: servbay-tls

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

Metoda trzecia: Przekierowanie portów (NAT)

Jeśli jest tylko jeden backend, możesz na routerze przekierować porty bezpośrednio na ServBay (192.168.1.115 w LAN).

Zalecane: przekieruj 443 i zachowaj HTTPS

Przekierowania: publiczny 443 → 192.168.1.115:443 (oraz publiczny 80 → 192.168.1.115:80 by ServBay robił redirect).
Rekord DNS A wskazuje na publiczne IPv4.
Tryb strony HTTP & HTTPS. Dostęp bezpośrednio z internetu wymaga zaufanego publicznie certyfikatu (jak poniżej), inaczej przeglądarki wyświetlą ostrzeżenie.
Sprawdź spójność IPv4 / IPv6 (niżej).

HTTP 80 bez HTTPS — tylko w wyjątkowych sytuacjach

Jeśli przekierujesz tylko port 80 i przełączysz stronę w tryb HTTP, tracisz wszelkie zalety HTTPS/HTTP2, oraz ryzykujesz starcie z HSTS/cachami przeglądarek. Tylko dla zaawansowanych i w pełni świadomych. Jeśli musisz: ustaw tryb na HTTP (by nie przekierowywać na zamknięty 443) i przekieruj wyłącznie 80.

Spójność IPv4 / IPv6

Jedna z najczęstszych przyczyn problemów z dostępem. Jeśli domena ma zarówno rekord A (IPv4), jak i AAAA (IPv6), część żądań klientów (Happy Eyeballs) przejdzie po IPv6. Jeśli obsłużysz tylko IPv4 (reverse proxy, przekierowanie), żądania po IPv6 będą zawodzić. Są dwie opcje:

Tylko IPv4: sprawdź, czy dig AAAA twojadomena +short nie zwraca wyniku — zostaw tylko rekord A.
Pełna obsługa IPv6: dodaj przekierowanie/obsługę IPv6 w reverse proxy, zadbaj o dostęp także backendów po IPv6.

Lista kontrolna problemów z dostępnością

Gdy są kłopoty z otwarciem stron (brak odpowiedzi, timeout, błędy certyfikatu, błędy strony), diagnostyka (przykład: example.com, backend 192.168.1.115):

Czy to przekierowanie 301 na nieudostępniony 443?
bash
```
curl -I http://example.com
```
1
Odpowiedź 301 i Location: https://..., a 443 nie działa → to ten powód. Skonfiguruj HTTPS (zalecane) lub przełącz stronę na HTTP.

IPv6 robi zamieszanie?

bash

curl -4 -I https://example.com     # Wymuś IPv4
curl -6 -I https://example.com     # Wymuś IPv6
dig A example.com +short
dig AAAA example.com +short        # Jest AAAA, a IPv6 nie działa → usuń lub napraw IPv6

SNI/certyfikat powrotu poprawny? (reverse proxy po HTTPS): bezpośrednie żądanie z SNI:
bash
```
curl -I --resolve example.com:443:192.168.1.115 https://example.com \
     --cacert /path/servbay-ca-bundle.crt
```
1
2
Błąd certyfikatu/niepasująca strona? Zwykle SNI lub CA nieustawione poprawnie.
Czy ruch dochodzi do ServBay? Na backendzie sprawdź log serwera (opcja „Pokaż log” w ServBay). Jeśli w logu nie ma zapytania — problem jest wyżej (proxy/router).
Nagłówek Host w porządku? (reverse proxy L7)
bash
```
curl -k -I -H "Host: example.com" https://192.168.1.115/
```
1
Bezpośrednio wszystko działa, przez proxy nie — proxy nie przekazuje Host.

Certyfikaty i bezpieczeństwo

Połączenie zwrotne: Reverse proxy → ServBay po HTTPS — dodaj zaufanie do CA ServBay (ServBay-Private-CA-ECC-Root.crt, w razie potrzeby razem z intermediate). To lokalna sieć zaufania, konfigurujesz tylko raz.
Certyfikat publiczny: Klientom w internecie pokaż zaufany, publiczny certyfikat. Reverse proxy zarządza nimi (Caddy/Traefik automatycznie). W trybie bezpośredniego połączenia (przekierowanie portów) musisz dodać publiczny certyfikat samodzielnie — wskazówki ACME. Certyfikat ServBay User CA nadaje się tylko do użytku lokalnego/LAN, nie jest zaufany publicznie.
Nie udostępniaj baz danych! Udostępniając WWW do internetu, nie otwieraj portów MySQL, Redis, Memcached itd. Hardening znajdziesz w Bezpiecznym dostępie w LAN.
Firewall: Otwórz tylko niezbędne porty, resztę zablokuj.

Często zadawane pytania (FAQ)

Lokalnie działa, nie działa z internetu — DNS?
- Zazwyczaj nie chodzi o DNS, lecz o przekierowanie 301 na nieaktywny 443, błędny SNI/certyfikat, brak Host, niespójny IPv4/IPv6. Przejdź po kolei przez listę kontrolną.
Czy trzeba przechodzić na HTTP 80, żeby reverse proxy działało?
- Nie i nie jest to zalecane. Zachowaj HTTP & HTTPS, reverse proxy niech łączy się po HTTPS, ufając CA ServBay lub wyłączając weryfikację. Zyskasz szyfrowanie end-to-end i wsparcie HTTP/2.
Reverse proxy zgłasza błąd certyfikatu lub złej strony?
- Sprawdź czy SNI (domena strony) jest wysyłane prawidłowo, a proxy ufa CA ServBay (w razie potrzeby razem z intermediate). Najprościej: wyłącz weryfikację na test, potem ją załącz.
Czy ServBay nadaje się do produkcji jako backend?
- Tak, wielu użytkowników stabilnie publikuje ServBay (Mac mini, Windows w kolokacji itd.). Klucz: właściwy tryb protokołu, SNI, Host, zaufanie do CA oraz spójność IPv4/IPv6.
Nie mam publicznego IP, co mogę zrobić?
- Skorzystaj z [Metody 1: Tunelowania] (#metoda-1-wbudowane-tunele-najprostsze-bez-publicznego-ip) (cloudflared / frpc), nie potrzebujesz publicznego IP ani przekierowania portów.

Podsumowanie

Upublicznienie ServBay jako serwera backendowego jest technicznie możliwe. Zalecana ścieżka to: zachowaj tryb HTTP & HTTPS na stronie, reverse proxy połącz przez HTTPS powrotny, wysyłaj poprawne SNI i zaufaj CA ServBay — zyskujesz szyfrowanie end-to-end i HTTP/2. Brak publicznego IP? Skorzystaj z tuneli cloudflared/frpc. Przekierowanie portów polecane wyłącznie świadomym użytkownikom. W przypadkach problemów z dostępem korzystaj z podanej tu listy kontrolnej — problemy niemal zawsze wynikają z ustawień protokołu, SNI/certyfikatu, nagłówka Host lub konfiguracji IPv4/IPv6.

Publikacja strony ServBay do internetu (reverse proxy, tunelowanie i przekierowanie portów) ​

Zrozum domyślne zachowanie sieciowe ServBay ​

Trzy metody publikacji — która wybrać? ​

Metoda 1: Wbudowane tunele (najprostsze, bez publicznego IP) ​

Metoda 2: Reverse proxy + HTTPS powrót (zalecane) ​

Dlaczego HTTPS powrotny, a nie HTTP 80? ​

Kluczowe punkty dla wszystkich reverse proxy ​

Pozyskanie ServBay CA dla reverse proxy ​

Reverse proxy Nginx (HTTPS powrót) ​

Reverse proxy HAProxy (HTTPS powrót) ​

Reverse proxy Caddy (HTTPS powrót) ​

Reverse proxy Traefik (HTTPS powrót) ​

Metoda trzecia: Przekierowanie portów (NAT) ​

Spójność IPv4 / IPv6 ​

Lista kontrolna problemów z dostępnością ​

Certyfikaty i bezpieczeństwo ​

Często zadawane pytania (FAQ) ​

Podsumowanie ​