Memublikasikan Situs ServBay ke Internet Publik (Reverse Proxy, Tunnel, & Port Forwarding)

Selain digunakan untuk pengembangan lokal, banyak pengguna menjalankan ServBay di server yang beroperasi 24 jam (Mac mini di data center, PC kantor, server Windows, dll) sebagai origin server backend, lalu mempublikasikan situs mereka ke internet publik. Pendekatan ini sepenuhnya layak secara produksi—sudah banyak pengguna menjalankannya dengan stabil.

Namun, jika Anda tidak memahami perilaku jaringan default ServBay, mudah terjebak pada masalah seputar protokol, sertifikat, header Host, atau jaringan, sehingga terjadi masalah seperti "lokal lancar, tapi akses publik bermasalah". Artikel ini ditujukan bagi siapa saja yang ingin menggunakan ServBay sebagai origin server. Akan dijelaskan perilaku defaultnya, disusul solusi lengkap menurut urutan "Tunnel Bawaan → Reverse Proxy (Rekomendasi) → Port Forwarding", dan ditutup dengan checklist troubleshooting umum.

Platform yang Didukung

Artikel ini berlaku untuk ServBay untuk macOS dan ServBay untuk Windows. Mode protokol, perilaku listening, dan pola path sertifikat di kedua platform adalah sama, hanya root instalasinya yang berbeda (macOS: /Applications/ServBay, Windows biasanya C:\ServBay, sesuaikan dengan instalasi Anda). Web server default juga berbeda: macOS default Caddy, Windows default Nginx, dan keduanya bisa diganti ke Nginx/Apache/Caddy.

Memahami Perilaku Jaringan Default ServBay

Sebagian besar kendala akses publik bersumber dari salah paham terhadap perilaku berikut:

Mode protokol situs default adalah HTTP & HTTPS. Dalam mode ini, akses HTTP (80) akan selalu 301 redirect ke HTTPS (443). Ini adalah pengaturan modern—Anda sebaiknya mengikuti ke HTTPS, bukan kembali ke HTTP 80 polos.
HTTPS memilih situs & sertifikat berdasarkan SNI. Pada satu ServBay dengan banyak situs, pemilihan dilakukan berdasarkan SNI (domain situs) saat TLS handshake. Saat reverse proxy ke backend HTTPS, wajib mengirimkan SNI yang benar, jika tidak akan mendapat situs/sertifikat default.
Default mendengarkan di semua network interface (0.0.0.0), port HTTP 80 / HTTPS 443 terbuka, sehingga umumnya sudah bisa menerima akses eksternal tanpa perlu mengubah binding.
Sertifikat HTTPS lokal diterbitkan oleh ServBay CA. ServBay memiliki CA lokal bawaan (muncul di keychain sebagai ServBay User CA - ECC Root) untuk menandatangani sertifikat situs Anda. Browser publik tidak akan mempercayainya—tetapi reverse proxy cukup mempercayai CA ini (atau melewati verifikasi), tanpa perlu mengajukan sertifikat publik khusus untuk backend.

Salah Kaprah Umum: HTTP & HTTPS + Hanya Forward 80

Jika situs tetap di HTTP & HTTPS tetapi hanya mem-forward 80, tanpa mengurus 443: client minta ke http://domain → ServBay balas 301 ke https://domain → client coba akses 443 → tidak ada yang merespon → gagal. Browser dan HSTS juga akan menyimpan redirect 301 ini, makin menyulitkan debugging.

Solusi yang benar adalah menyelesaikan akses HTTPS (lihat solusi reverse proxy di bawah), bukan mundur ke HTTP 80.

Pilihan Cara Publikasi & Panduan

Metode	Penjelasan	Cocok untuk
Tunnel Bawaan (frpc / cloudflared, dll)	Disediakan ServBay, membangun tunnel keluar tanpa perlu IP publik ataupun buka port	Tidak punya IP publik, rumahan / NAT, ingin metode tercepat
Reverse Proxy di Depan (Rekomendasi)	Nginx/HAProxy/Caddy/Traefik menerima trafik publik & kelola sertifikat, lalu HTTPS backend ke ServBay	Tersedia akses publik, perlu satu entry point / multi-backend / sentralisasi sertifikat
Port Forwarding (NAT)	Gateway langsung mapping port publik ke host ServBay	Hanya punya satu backend & tahu risikonya

Metode 1: Tunnel Bawaan (Paling Mudah, Tanpa IP Publik)

Jika Anda tidak memiliki IP publik, atau ingin menghindari kerumitan reverse proxy & sertifikat, layanan tunnel bawaan ServBay adalah opsi paling praktis. Tunnel ini membuka koneksi dari dalam, otomatis mengatasi masalah NAT, IPv6, port forwarding, dan kepercayaan sertifikat:

Cloudflare Tunnel (cloudflared) — Ekspos situs lokal ke jaringan Cloudflare global, otomatis mendapat HTTPS publik terpercaya, tanpa buka port. Cocok untuk kebutuhan domain + CDN / WAF stabil.
frp (frpc) — Koneksi ke server frps Anda sendiri, sepenuhnya mandiri & privat.
ngrok / Pinggy — Dengan cepat membuat URL publik sementara, cocok untuk demo, testing webhook, dan integrasi cepat.

Bagi sebagian besar pengguna, cukup menggunakan cloudflared untuk membangun satu tunnel sudah memadai untuk "memublikasikan situs lokal ke internet publik", tanpa harus menyimak metode reverse proxy/port forwarding setelahnya.

Metode 2: Reverse Proxy + HTTPS Backend (Rekomendasi)

Inilah praktik terbaik lingkungan produksi: reverse proxy di depan menyediakan HTTPS publik terpercaya, dan saat mengakses ServBay tetap gunakan HTTPS (mode HTTP & HTTPS tetap aktif) sehingga enkripsi terjaga end-to-end.

Kenapa HTTPS Backend Lebih Disarankan dari Sekadar HTTP 80

Banyak tutorial di luar masih menyarankan backend HTTP polos. Kami tidak menyarankan kecuali Anda memahami seluruh risikonya:

Enkripsi end-to-end: Meski reverse proxy & ServBay di LAN, seluruh trafik tetap terenkripsi, menghindari sniffing & modifikasi.
Fitur protokol modern: Dengan HTTPS, reverse proxy bisa mengaktifkan HTTP/2 (h2) untuk multiplexing, compression, connection reuse, dsb. HTTP polos mengunci Anda di protokol lama.
Menghindari masalah saat downgrade: Begitu turun ke HTTP, Anda akan hadapi masalah endless HTTP & HTTPS 301 redirect, caching HSTS browser, pembuatan tautan aplikasi https, dsb.
Trust CA ServBay sangat mudah: Tak masalah ServBay pakai CA self-sign—proxy cukup mempercayai CA tersebut, atau skip verification, cukup sekali konfigurasi berlaku jangka panjang.

Untuk penggunaan HTTP 80 polos, lihat Metode 3—khusus bagi yang benar-benar perlu & paham konsekuensinya.

Prinsip Umum

Prinsip berikut berlaku untuk semua proxy server. Contoh: domain publik example.com, backend ServBay 192.168.1.115, backend HTTPS port 443, mode situs ServBay tetap HTTP & HTTPS.

Proxy ke HTTPS: Gunakan proxy_pass / upstream ke https://192.168.1.115:443.
Kirim SNI yang benar: SNI harus sama dengan domain situs di ServBay (example.com). Salah SNI = salah sertifikat/situs.
Percayai CA ServBay (disarankan) atau skip verifikasi: Lihat panduan mendapat file CA di bawah.
Forward host header asli: Host: example.com untuk kecocokan server_name di ServBay.
Kirim X-Forwarded-Proto: https: Agar aplikasi backend tahu request asli HTTPS—hindari tautan http atau redirect berulang.
Konsistensi IPv4 / IPv6: Lihat IPv4/IPv6 konsisten.

Mengambil File ServBay CA (Agar Proxy Percaya Sertifikat Backend)

File root CA ServBay ada pada direktori instalasi ServBay:

macOS: /Applications/ServBay/ssl/private/ServBay-Private-CA-ECC-Root.crt
Windows: C:\ServBay\ssl\private\ServBay-Private-CA-ECC-Root.crt (sesuaikan dengan path aktual)

Copy file .crt ini ke server reverse proxy (misal /etc/nginx/servbay-ca/) dan konfigurasikan sebagai trusted CA pada backend proxy.

Tentang Certificate Chain

ServBay memakai struktur "Root CA + Intermediate CA". Sertifikat situs diterbitkan Intermediate CA. Bila proxy hanya percaya root CA tapi gagal validasi, gabungkan root dan intermediate (ServBay-Private-CA-ECC-Intermediate.crt di folder yang sama) jadi CA bundle. Proksi bisa sementara menggunakan mode "skip verification" uji coba, lalu beralih ke verifikasi total.

Reverse Proxy Nginx (HTTPS Backend)

nginx

server {
    listen 443 ssl;
    listen [::]:443 ssl;                 # Untuk dukungan IPv6
    server_name example.com;

    # Sertifikat publik (misal 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 backend

        # —— Kunci: SNI & verifikasi backend ——
        proxy_ssl_server_name on;                             # Kirim SNI
        proxy_ssl_name        example.com;                    # SNI = domain ServBay
        proxy_ssl_trusted_certificate /etc/nginx/servbay-ca/servbay-ca-bundle.crt;
        proxy_ssl_verify      on;                             # Dengan CA ServBay, aktifkan verifikasi
        proxy_ssl_verify_depth 2;                             # Root + intermediate = 2
        # Opsi mudah (tanpa CA): proxy_ssl_verify off;

        # —— Forward Host & proto asli ——
        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 ke HTTPS oleh 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
    # HTTPS backend: aktifkan ssl + kirim SNI + trust 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
    # Opsi mudah: server servbay1 192.168.1.115:443 ssl sni str(example.com) verify none

Reverse Proxy Caddy (HTTPS Backend)

Caddy otomatis mengelola sertifikat publik untuk example.com, dan reverse_proxy secara default me-forward Host dan 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
            # Opsi mudah: tls_insecure_skip_verify
        }
    }
}

Reverse Proxy Traefik (HTTPS Backend)

Contoh konfigurasi file provider dinamis:

yaml

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

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

Metode 3: Port Forwarding (NAT)

Jika hanya memiliki satu backend, Anda bisa langsung mapping port publik di gateway/router ke ServBay host (misalkan IP LAN 192.168.1.115).

Direkomendasikan: Forward 443, tetap pakai HTTPS

Port forwarding gateway: Public 443 → 192.168.1.115:443 (plus public 80 → 192.168.1.115:80 agar ServBay redirect sendiri 80 ke 443).
DNS arahkan record A ke IPv4 publik.
Situs tetap pada HTTP & HTTPS. Karena pengunjung langsung akses ServBay, pastikan domain memakai sertifikat publik terpercaya (lihat penjelasan sertifikat setelah ini), jika tidak browser akan memberi peringatan sertifikat.
Cek konsistensi IPv4/IPv6 (lihat bawah).

HTTP 80 Polos (Hanya Untuk Kasus Khusus)

Hanya forward 80 dan ubah mode situs ke HTTP berarti Anda menyerah pada manfaat HTTPS & HTTP/2, dan rentan bentrok dengan cache HSTS browser. Sangat tidak dianjurkan kecuali paham dampaknya. Jika tetap harus: set website ke mode HTTP (agar tak redirect 301 ke 443 yang tidak dibuka), dan forward-lah hanya port 80.

Konsistensi IPv4 / IPv6

Penyebab umum akses publik tidak stabil. Jika domain memiliki record A (IPv4) dan AAAA (IPv6), client terkadang memilih prioritas ke IPv6; jika hanya set up forward/reverse proxy pada IPv4, request via IPv6 akan gagal. Dua solusi:

Hanya IPv4: Pastikan dig AAAA domainAnda +short kosong; hanya sisakan record A.
Dual Stack: Atur port forwarding juga untuk IPv6, pastikan reverse proxy agar listening ke [::], dan backend dapat dijangkau via IPv6.

Checklist Troubleshooting Akses Publik

Jika akses publik error (tidak bisa dibuka, timeout, error sertifikat, salah situs, dll) urutkan troubleshooting (domain example.com, backend 192.168.1.115):

Apakah ada redirect 301 ke 443 yang tidak dibuka?
bash
```
curl -I http://example.com
```
1
Jika hasil 301 dengan Location: https://... dan 443 belum di-handle → inilah masalahnya. Selesaikan setup HTTPS, atau ubah situs ke mode HTTP (tidak direkomendasikan).

IPv6 menyebabkan masalah?

bash

curl -4 -I https://example.com     # Paksa IPv4
curl -6 -I https://example.com     # Paksa IPv6
dig A example.com +short
dig AAAA example.com +short        # Ada AAAA tapi IPv6 tidak connect? Hapus AAAA / aktifkan IPv6

SNI / sertifikat backend sudah tepat? (pada HTTPS backend) Tes koneksi SNI ke backend:
bash
```
curl -I --resolve example.com:443:192.168.1.115 https://example.com \
     --cacert /path/servbay-ca-bundle.crt
```
1
2
Jika error sertifikat/domain tidak cocok, kemungkinan SNI salah atau CA tidak dipercayai.
Koneksi sudah masuk ke ServBay? Cek access log web server untuk situs di ServBay ("Lihat Log File" di ServBay). Jika tidak muncul, ada masalah di jaringan/gateway/proxy.
Host header benar? (pada reverse proxy layer 7)
bash
```
curl -k -I -H "Host: example.com" https://192.168.1.115/
```
1
Jika koneksi langsung lancar, tapi lewat proxy error → reverse proxy tidak mem-forward host header.

Sertifikat & Keamanan

Koneksi backend: Reverse proxy → ServBay harus menggunakan HTTPS. Proxy perlu mempercayai ServBay CA (ServBay-Private-CA-ECC-Root.crt, gabungkan intermediate jika perlu); cukup sekali setup.
Sertifikat publik: Untuk pengunjung internet, sertifikat harus publik & terpercaya. Reverse proxy dapat mengelola otomatis (Caddy/Traefik), jika direct (port forwarding) Anda perlu pasang sertifikat ini di ServBay (baca Menggunakan ACME untuk Sertifikat SSL). Sertifikat self-signed ServBay hanya untuk lokal/LAN, tidak dipercaya publik.
Jangan tanpa sengaja expose database: Pastikan hanya port web yang dibuka ke publik—MySQL, Redis, Memcached dll jangan dikasih akses. Baca Keamanan pada akses LAN.
Firewall: Hanya buka port yang diperlukan, tutup semua lainnya.

FAQ (Pertanyaan Umum)

Q: Lokal lancar, publik error—apakah masalah DNS?
- A: Biasanya bukan soal "tidak resolve", tapi karena 301 HTTP & HTTPS ke 443 yang belum diatur, SNI/sertifikat salah, Host header tidak diteruskan, atau masalah IPv4/IPv6. Cek checklist di atas.
Q: Apakah harus mundur ke HTTP 80 agar reverse proxy bisa?
- A: Tidak, dan tidak direkomendasikan. Tetap gunakan HTTP & HTTPS, reverse proxy ke backend HTTPS, percayai CA ServBay (atau skip verification), dapatkan enkripsi end-to-end dan HTTP/2.
Q: Proxy ke backend error sertifikat/situs?
- A: Pastikan SNI benar (=domain), reverse proxy percaya CA ServBay (sertakan intermediate jika perlu). Uji dulu dengan skip verification, lalu beralih ke verifikasi strict.
Q: Apakah ServBay di server produksi stabil?
- A: Ya. Banyak pengguna menjalankan ServBay di Mac mini/server Windows dengan layanan publik yang stabil. Kunci: mode protokol, SNI, Host header, CA trust, dan konsistensi IPv4/IPv6.
Q: Bagaimana jika tidak punya IP publik?
- A: Pakai Metode 1: Tunnel Bawaan (cloudflared/frpc), tidak memerlukan IP publik atau port forwarding sama sekali.

Kesimpulan

Memublikasikan ServBay sebagai origin server backend ke internet publik sepenuhnya mungkin. Pilihan utama: gunakan mode HTTP & HTTPS, depan reverse proxy ke backend via HTTPS, kirim SNI benar, dan trust CA ServBay untuk enkripsi end-to-end dan fitur HTTP/2. Tanpa IP publik gunakan tunnel cloudflared/frpc bawaan. Port forwarding hanya untuk yang benar-benar paham risikonya. Jika kendala akses, gunakan checklist troubleshooting di atas—hampir pasti masalahnya hanya seputar mode protokol, SNI/sertifikat, Host header, atau IPv4/IPv6.

Memublikasikan Situs ServBay ke Internet Publik (Reverse Proxy, Tunnel, & Port Forwarding) ​

Memahami Perilaku Jaringan Default ServBay ​

Pilihan Cara Publikasi & Panduan ​

Metode 1: Tunnel Bawaan (Paling Mudah, Tanpa IP Publik) ​

Metode 2: Reverse Proxy + HTTPS Backend (Rekomendasi) ​

Kenapa HTTPS Backend Lebih Disarankan dari Sekadar HTTP 80 ​

Prinsip Umum ​

Mengambil File ServBay CA (Agar Proxy Percaya Sertifikat Backend) ​

Reverse Proxy Nginx (HTTPS Backend) ​

Reverse Proxy HAProxy (HTTPS Backend) ​

Reverse Proxy Caddy (HTTPS Backend) ​

Reverse Proxy Traefik (HTTPS Backend) ​

Metode 3: Port Forwarding (NAT) ​

Konsistensi IPv4 / IPv6 ​

Checklist Troubleshooting Akses Publik ​

Sertifikat & Keamanan ​

FAQ (Pertanyaan Umum) ​

Kesimpulan ​