Menerbitkan Website ServBay ke Publik (Reverse Proxy, Tunnel & Port Forwarding)

Selain digunakan untuk development lokal, banyak pengguna memilih men-deploy ServBay di server permanen (seperti Mac mini di data center, PC kantor, server Windows, dll), sebagai backend origin server, lalu menerbitkan website ke Internet publik untuk melayani klien. Ini praktik umum di produksi—sudah banyak pengguna yang menjalankan setup seperti ini secara stabil.

Namun, jika Anda tidak memahami perilaku jaringan default ServBay, sering terjadi masalah protokol, sertifikat, Host header, dan jaringan, menghasilkan situasi “lokal normal, tapi akses publik bermasalah.” Artikel ini ditujukan untuk semua yang ingin memakai ServBay sebagai backend origin. Kita akan membahas perilaku default, lalu memandu solusi lengkap berurutan: Tunnel bawaan → Reverse Proxy (Disarankan) → Port Forwarding, dan di akhir menyediakan daftar troubleshoot akses umum.

Platform yang Didukung

Panduan ini berlaku untuk ServBay for macOS dan ServBay for Windows. Mode protokol website, perilaku listening port, dan lokasi file sertifikat identik di kedua platform; hanya direktori instalasi saja yang berbeda (macOS: /Applications/ServBay, Windows: C:\ServBay, sesuaikan dengan lokasi nyata). Web server default berbeda: macOS pakai Caddy, Windows pakai Nginx—keduanya dapat diganti ke Nginx / Apache / Caddy.

Memahami Perilaku Jaringan Default ServBay

Mayoritas masalah akses publik berasal dari salah paham tentang perilaku default berikut:

Protokol default website adalah HTTP & HTTPS. Pada mode ini, akses HTTP (port 80) akan selalu 301 redirect ke HTTPS (443). Ini default modern yang disengaja—lanjutkan pakai HTTPS, jangan mundur ke HTTP 80 yang tidak aman.
HTTPS memilih website & sertifikat via SNI. Jika ada banyak website di ServBay, pemetaan didasarkan pada SNI di handshake TLS (setara dengan domain website). Reverse proxy yang upstream via HTTPS wajib kirim SNI dengan benar, jika tidak akan mendapat sertifikat/site default.
By default listen di semua interface (0.0.0.0), port default HTTP 80 / HTTPS 443—otomatis terbuka untuk akses eksternal, umumnya tak perlu ganti binding address.
Sertifikat HTTPS lokal diterbitkan oleh ServBay CA. ServBay memiliki CA lokal bawaan (ServBay User CA - ECC Root) untuk menandatangani sertifikat website. Browser publik tidak percayai CA ini secara default—cukup buat reverse proxy Anda mempercayai CA ini (atau skip verifikasi), tanpa perlu request sertifikat publik tambahan untuk backend.

Salah Kaprah Umum: HTTP & HTTPS + Hanya Forward 80

Jika website tetap HTTP & HTTPS, tapi hanya port 80 yang diforward, tidak 443: klien request http://domain → ServBay kirim 301 https://domain → klien konek ke 443 → tak ada yang jawab → akses gagal. Browser dan HSTS bisa cache 301 ini, membuat troubleshoot makin sulit.

Solusi bukan mundur ke HTTP 80, melainkan pastikan HTTPS berfungsi (lihat bagian reverse proxy di bawah).

Pilih Salah Satu dari 3 Metode Publikasi

Metode	Penjelasan	Skema Ideal
Tunnel Bawaan (frpc / cloudflared dst)	Built-in ServBay, inisiasi koneksi keluar, tak butuh IP publik atau buka port	Tak ada IP publik, jaringan NAT/rumahan, mau cara kilat
Reverse Proxy Depan (Disarankan)	Publik masuk via Nginx/HAProxy/Caddy/Traefik, manajemen sertifikat, HTTPS upstream ke ServBay	Ada pintu masuk publik, butuh satu endpoint/multi-backend/pusat sertifikat
Port Forwarding (NAT)	Gateway langsung forward port ke host ServBay	Hanya satu backend, paham risiko teknik

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

Tak ada IP publik atau sekadar ingin cara praktis tanpa utak-atik proxy/sertifikat? Layanan tunnel ServBay adalah solusi termudah. Tunnel dibuka dari dalam, otomatis mem-bypass masalah NAT, IPv6, forward port, atau kepercayaan sertifikat, misalnya:

Cloudflare Tunnel (cloudflared) — Expose website lokal ke Cloudflare global, otomatis dapat HTTPS publik valid, tak perlu buka port. Cocok untuk kebutuhan domain publik stabil + CDN/WAF.
frp (frpc) — Koneksi ke server frps milik sendiri, kontrol penuh.
ngrok / Pinggy — Bikin URL publik temporer, bagus untuk demo & webhook.

Bagi banyak pengguna, cukup membangun tunnel cloudflared sudah mampu memenuhi “website lokal jadi bisa diakses publik”—tak perlu lanjut ke reverse proxy/port forwarding.

Metode 2: Reverse Proxy Depan + HTTPS Upstream (Paling Direkomendasikan)

Inilah cara terbaik untuk produksi: reverse proxy di depan beri HTTPS publik terpercaya, upstream ke backend ServBay juga via HTTPS (tetap HTTP & HTTPS di ServBay)—dapat full end-to-end encryption.

Kenapa HTTPS Upstream Disarankan, Bukan Kembali ke HTTP 80

Banyak tutorial lawas menyarankan backend tetap HTTP, proxy upstream pakai cleartext. Kami tidak menyarankan praktek lama itu kecuali Anda benar-benar paham resikonya:

Enkripsi End-to-End: Meski reverse proxy & ServBay masih di LAN, traffic tetap terenkripsi, mencegah sniffing dan manipulasi lokal.
Dapat Fitur Protokol Modern: Jalur HTTPS saja yang memungkinkan frontend HTTP/2 (h2), mendapatkan pipelining, kompresi header, multiplexing koneksi, dsb; HTTP 80 mengunci Anda di paradigma usang.
Cegah Masalah Downgrade: Turun ke HTTP perlu menangani 301, caching HSTS, auto-generate link https di aplikasi, dan masalah lain.
Trust ServBay CA Itu Mudah: Tak apa pakai CA self-signed ServBay—tinggal tambahkan ke trusted CA reverse proxy atau lewati saja verification.

Skema HTTP 80 boleh dipilih lewat Metode 3, hanya untuk kasus khusus yang sadar resikonya.

Poin Umum yang Berlaku untuk Semua Reverse Proxy

Prinsip di bawah ini berlaku untuk semua (Nginx, HAProxy, Caddy, Traefik)—misal, domain publik example.com, backend ServBay 192.168.1.115, backend HTTPS port 443, mode ServBay HTTP & HTTPS.

HTTPS upstream: Konfigurasi proxy_pass/upstream langsung ke https://192.168.1.115:443.
Kirim SNI yang Benar: SNI sama persis dengan domain ServBay (example.com), supaya backend tahu pilih website/sertifikat mana.
Trusted ServBay CA/Skip Verification: Lihat panduan file CA pada sesi berikut.
Host Header Transparan: Host: example.com, membantu ServBay cocokkan ke server_name.
Set X-Forwarded-Proto: https: Biarkan aplikasi belakang tahu aslinya HTTPS, mencegah perulangan redirect http/https loop.
Konsistensi IPv4/IPv6: Lihat konsistensi IPv4/IPv6.

Lokasi ServBay CA (Untuk Trust Sertifikat Origin di Reverse Proxy)

File root CA ServBay dapat dicari di direktori instalasi berikut:

macOS: /Applications/ServBay/ssl/private/ServBay-Private-CA-ECC-Root.crt
Windows: C:\ServBay\ssl\private\ServBay-Private-CA-ECC-Root.crt (pastikan sesuai lokasi instalasi)

Copy file .crt ini ke server reverse proxy (misal, /etc/nginx/servbay-ca/), lalu masukkan ke konfigurasi sebagai trusted CA untuk upstream.

Tentang Certificate Chain

ServBay menggunakan “root CA + intermediate CA.” Jika trust ke root saja gagal divalidasi, gabungkan root dengan intermediate (ServBay-Private-CA-ECC-Intermediate.crt, ada di folder sama) menjadi satu CA bundle. Atau, awalnya gunakan mode skip verification, setelah jalur jalan baru beralih ke strict validation.

Konfigurasi Nginx Reverse Proxy (HTTPS Upstream)

nginx

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

    # Sertifikat publik terpercaya (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 upstream

        # —— Kunci: SNI & verifikasi upstream ——
        proxy_ssl_server_name on;                             # Aktifkan 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;                             # Enable verify setelah trust CA
        proxy_ssl_verify_depth 2;                             # Root + Intermediate
        # Cara simpel (tanpa CA): proxy_ssl_verify off;

        # —— Host & scheme transparan ——
        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;
    }
}

# Redirect HTTP ke HTTPS (proxy yang lakukan)
server {
    listen 80;
    listen [::]:80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

Konfigurasi HAProxy Reverse Proxy (HTTPS Upstream)

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 upstream: ssl + SNI + verifikasi ServBay 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
    # Cara simpel: server servbay1 192.168.1.115:443 ssl sni str(example.com) verify none

Konfigurasi Caddy Reverse Proxy (HTTPS Upstream)

Caddy otomatis request & renew sertifikat publik untuk example.com, reverse_proxy juga by default transparan Host/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
            # Cara simpel: tls_insecure_skip_verify
        }
    }
}

Traefik Reverse Proxy (HTTPS Upstream)

Contoh file provider dynamic:

yaml

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

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

Metode 3: Port Forwarding (NAT)

Jika hanya satu backend, cukup lakukan port forwarding di gateway/router agar publik bisa akses host ServBay (misal, IP 192.168.1.115).

Disarankan: Forward 443, Jaga HTTPS

Port forwarding: 443 publik → 192.168.1.115:443 (dan 80 publik → 192.168.1.115:80 agar ServBay redirect ke 443).
Atur DNS A record ke IP publik Anda.
Website tetap HTTP & HTTPS. Karena pengunjung langsung konek ke ServBay, domain wajib punya sertifikat publik valid (lihat petunjuk sertifikat di bawah), jika tidak browser akan beri warning.
Pastikan konsistensi IPv4/IPv6 (lihat sesi selanjutnya).

Jalur HTTP 80 tanpa enkripsi (hanya khusus!)

Forward cuma port 80 dan atur protokol website ke HTTP akan menyebabkan hilangnya benefit HTTPS dan HTTP/2 serta rentan kena cache/HSTS browser. Hanya lakukan jika sangat paham resiko dan memang diperlukan. Jika benar perlu: mode website buat ke HTTP, forward hanya 80.

IPv4 / IPv6 Konsistensi

Ini penyebab umum akses publik tak stabil. Jika domain punya record A (IPv4) dan AAAA (IPv6), kadang klien otomatis pilih IPv6. Jika forwarding/reverse proxy hanya cover IPv4, trafik via IPv6 akan gagal. Ada dua solusi:

Pakai IPv4 saja: Pastikan perintah dig AAAA domain +short tidak output, hanya punya record A.
Dukung IPv6 sekaligus: Atur forwarding/akses untuk IPv6 juga, set reverse proxy listen [::], dan pastikan backend bisa diakses via IPv6.

Checklist Troubleshoot Masalah Akses

Jika akses publik gagal/nge-hang/error sertifikat, troubleshooting dengan urutan berikut (domain example.com, backend 192.168.1.115):

Apakah diarahkan ke 443 yang tidak diforward?
bash
```
curl -I http://example.com
```
1
Jika output 301 dan Location: https://..., tapi Anda tidak forward 443 → inilah masalahnya. Buat jalur HTTPS, atau ganti mode site ke HTTP.

Apakah masalah IPv6?

bash

curl -4 -I https://example.com     # IPv4 saja
curl -6 -I https://example.com     # IPv6 saja
dig A example.com +short
dig AAAA example.com +short        # Ada AAAA tapi IPv6 tak jalan → hapus atau fix routingnya

Apakah SNI/sertifikat upstream benar? (HTTPS upstream) Tes langsung ke backend sertakan SNI:
bash
```
curl -I --resolve example.com:443:192.168.1.115 https://example.com \
     --cacert /path/servbay-ca-bundle.crt
```
1
2
Jika error non-cocok sertifikat/website, berarti SNI salah atau CA belum ditrust.
Apakah request sampai ke ServBay? Cek log akses web server untuk site terkait di host ServBay (menu “Lihat Log File” di ServBay). Jika request timeout tanpa log baru, problem ada di jaringan/gateway/reverse proxy Anda.
Apakah Host header benar? (untuk reverse proxy L7)
bash
```
curl -k -I -H "Host: example.com" https://192.168.1.115/
```
1
Langsung connect ke backend OK, via reverse proxy error → reverse proxy tidak transparan Host.

Sertifikat & Security

Jalur upstream: Reverse proxy → ServBay harus berjalan via HTTPS, jadikan reverse proxy trust ke ServBay CA (ServBay-Private-CA-ECC-Root.crt, bisa digabung intermediate jika error). Trust ini hanya di LAN, cukup sekali setting.
Sertifikat publik: Untuk klien umum, sertifikat mesti valid publik. Skema reverse proxy dihandle proxy (Caddy/Traefik auto-issue/renew); model port forwarding berarti Anda harus setup sertifikat publik langsung di ServBay. Lihat cara issue sertifikat via ACME. Sertifikat CA ServBay cocok untuk LAN/lokal, bukan untuk umum Internet.
Jangan sekalian expose database: Saat mengekspos website, pastikan port database (MySQL, Redis, Memcached, dst) tetap tertutup! Tips security lain baca akses LAN.
Firewall: Buka port hanya yang perlu, lainnya blok semua.

FAQ (Pertanyaan Umum)

T: Lokal OK, akses publik bermasalah. DNS error?
- J: Biasanya bukan masalah DNS, melainkan redirect 301 akibat HTTP & HTTPS ke port 443 yang tidak terbuka, SNI/sertifikat salah, Host header tidak transparan, atau IPv4/IPv6 tak sinkron. Cek dengan urut checklist di atas.
T: Apa reverse proxy harus ke HTTP 80?
- J: Tidak perlu, dan tidak disarankan. Biarkan HTTP & HTTPS, reverse proxy upstream via HTTPS dan trust ServBay CA (atau skip verify) untuk keamanan optimal & dukungan HTTP/2.
T: Kok upstream sertifikat error/website salah?
- J: Pastikan SNI dikirim sesuai domain, reverse proxy trust ke ServBay CA (jika perlu include intermediate). Test dulu dengan skip verify, setelah stable balik ke strict verify.
T: ServBay aman sebagai origin server produksi?
- J: Aman. Banyak user deploy ServBay di Mac mini/server Windows di IDC production. Yang penting konsistensi protokol, SNI, Host header, trust CA, dan IPv4/IPv6.
T: Gak punya IP publik, gimana?
- J: Gunakan Metode 1: Tunnel Bawaan (cloudflared/frpc)—tak butuh IP publik atau port forwarding.

Kesimpulan

Men-deploy ServBay sebagai backend origin ke Internet publik sepenuhnya feasible. Rekomendasi utama: tetap pakai mode HTTP & HTTPS di website, reverse proxy di depan upstream via HTTPS, kirim SNI yang benar dan trust ServBay CA—dapat keamanan end-to-end & fitur HTTP/2 yang modern. Jika tak ada IP publik, cukup manfaatkan tunnel cloudflared/frpc bawaan. Port forwarding hanya cocok untuk user advance yang sangat paham setup-nya. Jika akses bermasalah, checklist troubleshooting di atas sudah sangat membantu—umumnya problem ada di protokol, SNI/sertifikat, Host header, atau IPv4/IPv6.

Menerbitkan Website ServBay ke Publik (Reverse Proxy, Tunnel & Port Forwarding) ​

Memahami Perilaku Jaringan Default ServBay ​

Pilih Salah Satu dari 3 Metode Publikasi ​

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

Metode 2: Reverse Proxy Depan + HTTPS Upstream (Paling Direkomendasikan) ​

Kenapa HTTPS Upstream Disarankan, Bukan Kembali ke HTTP 80 ​

Poin Umum yang Berlaku untuk Semua Reverse Proxy ​

Lokasi ServBay CA (Untuk Trust Sertifikat Origin di Reverse Proxy) ​

Konfigurasi Nginx Reverse Proxy (HTTPS Upstream) ​

Konfigurasi HAProxy Reverse Proxy (HTTPS Upstream) ​

Konfigurasi Caddy Reverse Proxy (HTTPS Upstream) ​

Traefik Reverse Proxy (HTTPS Upstream) ​

Metode 3: Port Forwarding (NAT) ​

IPv4 / IPv6 Konsistensi ​

Checklist Troubleshoot Masalah Akses ​

Sertifikat & Security ​

FAQ (Pertanyaan Umum) ​

Kesimpulan ​