將 ServBay 網站發布到公網（反向代理、隧道與埠轉發）

除了本機開發，許多使用者會將 ServBay 部署於常駐伺服器（如機房托管的 Mac mini、辦公室主機、Windows 伺服器等），作為後端源站（origin server），再將網站發布到公網供外部使用。這種方式在生產環境中完全可行，且已有大量用戶穩定運行。

然而，若不了解 ServBay 預設的網路行為，往往在通訊協定、憑證、Host 標頭、網路等環節出現問題，導致「本地一切正常，公網卻無法訪問」。本文針對想用 ServBay 做為後端源站的使用者，先說明預設行為，再依「內建隧道 → 反向代理（推薦）→ 埠轉發」順序提供完整方案，最後附上通用的連線異常排查清單。

適用平台

本文同時適用於 ServBay for macOS 和 ServBay for Windows。兩平台網站協定模式、監聽行為、憑證路徑規則完全一致，僅安裝路徑不同（macOS 為 /Applications/ServBay，Windows 通常為 C:\ServBay，以實際安裝位置為準）。預設 Web 伺服器稍有差異：macOS 預設 Caddy，Windows 預設 Nginx，兩者均可切換至 Nginx / Apache / Caddy。

先理解 ServBay 的預設網路行為

絕大多數公網訪問問題，皆由下列預設行為誤解引起：

網站預設為 HTTP & HTTPS 模式。此模式下，HTTP(80) 請求會強制 301 轉址到 HTTPS(443)。這是現代化的預設，你應順勢啟用 HTTPS，而非回退明文 80。
HTTPS 透過 SNI 決定站點與憑證。同一台 ServBay 可跑多個網站，會根據 TLS 握手中的 SNI（即站點網域）進行匹配。反代做 HTTPS 回源時，SNI 必須正確，否則只會回傳預設站點或預設憑證。
預設監聽所有網路介面（0.0.0.0），預設埠為 HTTP 80 / HTTPS 443，自然允許外部訪問，通常不需調整綁定位址。
本地 HTTPS 憑證由 ServBay CA 簽發。ServBay 內建本地 CA（鑰匙串顯示 ServBay User CA - ECC Root），為你的網站頒發憑證。公網訪客預設不信任這張 CA——但於反向代理端信任此 CA（或跳過驗證）即可，無需為回源鏈路獨立申請官方 SSL 憑證。

典型誤區：HTTP & HTTPS + 只做 80 埠轉發

如果網站保持 HTTP & HTTPS，只轉發 80 而未處理 443：用戶請求 http://網域 → ServBay 回 301 https://網域 → 用戶連不上 443 → 訪問失敗。瀏覽器與 HSTS 還會快取此 301，讓排查更困難。

正確方式不是回退 HTTP 80，而是把 HTTPS 跑通（詳見下文反向代理方案）。

三種發布方式如何選擇

方式	說明	適用場景
內建隧道（frpc / cloudflared 等）	ServBay 內建，主動對外建立隧道，無需公網 IP、無需開埠	沒有公網 IP、家庭 / NAT 網路、想快速外部發布
前置反向代理（推薦）	使用 Nginx/HAProxy/Caddy/Traefik 負責公網連線與憑證，再HTTPS 回源至 ServBay	有公網存取需求、需統一入口 / 多後端 / 集中憑證
埠轉發（NAT）	路由器直接將公網埠導向 ServBay 主機	僅一台後端、並明確知悉風險

方式一：內建隧道（最簡單，無需公網 IP）

如果你沒有公網 IP，或不想處理反向代理與憑證，ServBay 內建隧道功能最省事。它們主動由 ServBay 發起連線，天然繞過 NAT、IPv6、埠轉發與憑證信任等問題：

Cloudflare Tunnel（cloudflared） — 透過 Cloudflare 全球網路公開本地站點，自動提供被公網信任的 HTTPS，無須開啟任何埠。適合需穩定公網網域 + CDN / WAF 的情境。
frp（frpc） — 連接你自建的 frps 伺服器，完全自主。
ngrok / Pinggy — 快速生成臨時公網網址，適合展示、Webhook 聯調。

對於多數用戶，以 cloudflared 建一條隧道就能滿足「將本地站點發布到公網」的需求，無需繼續閱讀後方的反向代理或埠轉發方案。

方式二：前置反向代理 + HTTPS 回源（推薦）

這是生產環境推薦路線：前置反代於外部提供可信的 HTTPS，回源 ServBay 時同樣採 HTTPS（保留網站 HTTP & HTTPS 模式），實現端到端加密。

為什麼推薦 HTTPS 回源而非退回 HTTP 80

多數網路教學仍停留在「後端跑 HTTP、反代回源走明文」的做法。我們不建議這樣，除非你有非常特殊需求並明白其後果：

端到端加密：即使反代與 ServBay 在同一區網，流量全程加密，避免內網被攔截或中間人篡改。
現代協定能力：僅用 HTTPS 方能在前端順利啟用 HTTP/2（h2），享受多路復用、頭壓縮、連線重用等效能優勢；明文 80 會限制於舊架構。
避免降級導致疑難雜症：一旦回退 HTTP，會受困於 301 跳轉、HSTS 快取、應用層 https 鏈結產生等衍生問題。
信任 ServBay CA 很簡單：ServBay 用自簽 CA 無礙，只需於反代理端信任此 CA，或略過回源驗證，一次設定長期有效。

明文 HTTP 80 方案請見方式三，僅建議非常了解情境與風險的使用者。

通用重點

以下為所有四種反代通用重點，範例以：公網網域 example.com、ServBay 內網位址 192.168.1.115、後端 HTTPS 為 443、網站協定持續 HTTP & HTTPS。

HTTPS 回源：反代理 proxy_pass/upstream 指向 https://192.168.1.115:443。
發送正確 SNI：SNI 必須等於 ServBay 站點網域（example.com），否則 ServBay 無法以 SNI 選正確站點及憑證。
信任 ServBay CA（推薦）或跳過驗證（簡易）：見下節如何取得 CA 憑證檔案。
透傳 Host 標頭：Host: example.com，供 ServBay server_name 匹配。
傳遞 X-Forwarded-Proto: https：讓後端應用知道原始連線為 https，避免產生 http 鏈結或重導迴圈。
IPv4 / IPv6 一致：請見IPv4/IPv6 一致性。

取得 ServBay CA（供反代信任回源憑證）

ServBay 的本地根 CA 憑證檔案位於安裝目錄：

macOS：/Applications/ServBay/ssl/private/ServBay-Private-CA-ECC-Root.crt
Windows：C:\ServBay\ssl\private\ServBay-Private-CA-ECC-Root.crt（實際安裝路徑為準）

將 .crt 檔案拷貝到反向代理伺服器（如 /etc/nginx/servbay-ca/），於反代設定裡做為回源驗證的信任 CA。

關於憑證鏈

ServBay 採「根 CA + 中介 CA」兩層結構，網站憑證由中介 CA 簽發。若反代僅信任根 CA 造成驗證失敗，可將根與中介憑證（位於同目錄 ServBay-Private-CA-ECC-Intermediate.crt）合併為 CA bundle 給反代信任；或先用「略過驗證」的簡易寫法測試，再切回嚴格驗證。

Nginx 反向代理（HTTPS 回源）

nginx

server {
    listen 443 ssl;
    listen [::]:443 ssl;                 # 若需支援 IPv6
    server_name example.com;

    # 公網對外的可信憑證（如 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 回源

        # —— 重要：SNI 與回源驗證 ——
        proxy_ssl_server_name on;                             # 送出 SNI
        proxy_ssl_name        example.com;                    # SNI = ServBay 站點網域
        proxy_ssl_trusted_certificate /etc/nginx/servbay-ca/servbay-ca-bundle.crt;
        proxy_ssl_verify      on;                             # 信任 ServBay CA 後啟用驗證
        proxy_ssl_verify_depth 2;                             # 根 CA + 中介 CA
        # 簡易方案（不設 CA）：proxy_ssl_verify off;

        # —— 重要：透傳 Host 與協定 ——
        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 跳轉 HTTPS（由反代統一處理）
server {
    listen 80;
    listen [::]:80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

HAProxy 反向代理（HTTPS 回源）

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 回源：ssl + 傳送 SNI + 驗證 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
    # 簡易方案：server servbay1 192.168.1.115:443 ssl sni str(example.com) verify none

Caddy 反向代理（HTTPS 回源）

Caddy 會自動為 example.com 申請與續約公網憑證，reverse_proxy 預設透傳 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
            # 簡易方案：tls_insecure_skip_verify
        }
    }
}

Traefik 反向代理（HTTPS 回源）

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
        servers:
          - url: "https://192.168.1.115:443" # HTTPS 回源
        serversTransport: servbay-tls

serversTransports:
  servbay-tls:
    serverName: example.com                  # SNI
    rootCAs:
      - /etc/traefik/servbay-ca/servbay-ca-bundle.crt
    # 簡易方案：insecureSkipVerify: true

方式三：埠轉發（NAT）

如僅有一台後端，可於網關/路由器直接將公網埠導向 ServBay 主機（假設內網 IP 192.168.1.115）。

建議：轉發 443，保留 HTTPS

網關埠轉發：公網 443 → 192.168.1.115:443（同時 公網 80 → 192.168.1.115:80 讓 ServBay 自行執行 80 跳 443）。
DNS 設定 A 記錄指向公網 IPv4。
網站持續設定為 HTTP & HTTPS。因公網訪客直接連 ServBay，須為網域設定公網可信憑證（下文說明），否則會有瀏覽器憑證警告。
確保 IPv4 / IPv6 一致（見下節）。

明文 HTTP 80 直連（僅限特殊情境）

只轉發 80 並將網站設為 HTTP 模式，會導致失去一切 HTTPS 與 HTTP/2 好處，並與瀏覽器 HSTS / 快取衝突。僅建議對情境完全明白者使用。若不得不如此，網站協定需顯式設為 HTTP（避免 301 指到未開的 443），且僅轉發 80。

IPv4 / IPv6 一致性

造成公網訪問不穩的常見原因。如果網域同時有 A（IPv4）和 AAAA（IPv6）紀錄，客戶端 Happy Eyeballs 機制會偶爾優先走 IPv6；若你只設定了 IPv4 反代/轉發，則 IPv6 部分會失敗。建議處理方式：

僅使用 IPv4：確認 dig AAAA 你的網域 +short 為空，只保留 A 紀錄。
同時支援 IPv6：IPv6 也需設定轉發與反代監聽 [::]，並確認後端可經 IPv6 連通。

連線異常排查清單

公網訪問出現異常（無法連線、超時、憑證錯誤、錯誤路由等）時，建議依序檢查（網域 example.com、後端 192.168.1.115）：

是否 301 到未開放的 443？
bash
```
curl -I http://example.com
```
1
若回傳 301 且 Location: https://...，但 443 未開通 → 問題所在。將 HTTPS 走通（推薦）或將站點設為 HTTP。

是否 IPv6 影響？

bash

curl -4 -I https://example.com     # 僅用 IPv4
curl -6 -I https://example.com     # 僅用 IPv6
dig A example.com +short
dig AAAA example.com +short        # 有 AAAA 但 IPv6 無法訪問→移除或修通

回源 SNI / 憑證正確嗎？（HTTPS 回源情境）對後端直接發送 SNI：
bash
```
curl -I --resolve example.com:443:192.168.1.115 https://example.com \
     --cacert /path/servbay-ca-bundle.crt
```
1
2
如回報憑證/站點不匹配，多半是 SNI 設定錯誤或 CA 未信任。
請求有進到 ServBay 嗎？ 於 ServBay 主機檢查網站 Web 伺服器存取日誌（ServBay「查看 Log 檔案」）。若無紀錄，表示問題卡在網路層/網關/反代理。
Host 標頭正確嗎？（L7 反代）
bash
```
curl -k -I -H "Host: example.com" https://192.168.1.115/
```
1
直接連後端正常、經反代不正常 → 反代未透傳 Host。

憑證與安全

回源鏈路：反代 → ServBay 走 HTTPS 時，於反代端信任 ServBay CA（ServBay-Private-CA-ECC-Root.crt，如有需要合併中介憑證）；為內網信任用途，一次設定長期有效。
對外憑證：公網訪客憑證必須是公網可信憑證。反代理則由前端管理（Caddy/Traefik 可自動簽發續約）；埠轉發直連需於 ServBay 網站設定公網憑證，可參考ACME 申請憑證。ServBay 自簽 ServBay User CA 僅適合本地/局域網，公網用戶端基本不信任。
勿順便暴露資料庫：將 Web 對外公開時，嚴禁將 MySQL、Redis、Memcached 等埠同時開放。安全建議參見局域網訪問。
防火牆：僅開啟必要埠，其餘一律封鎖。

常見問題（FAQ）

Q：本機正常、公網異常，是 DNS 問題嗎？
- A：通常不是 DNS 錯誤，而是因 HTTP & HTTPS 的 301 指到未開 443、SNI/憑證沒對應、Host 標頭未透傳、或 IPv4/IPv6 不一致等。請依排查清單逐項檢驗。
Q：一定要回退 HTTP 80 才能實現反代嗎？
- A：完全不需要且不建議。請保留 HTTP & HTTPS，反代以 HTTPS 回源並信任 ServBay CA（或略過驗證），同時兼具端到端加密與 HTTP/2。
Q：反代回源憑證錯誤或站點有誤？
- A：請確認正確發送 SNI（= 站點網域）、反代信任了 ServBay CA（必要時含中介憑證）。可先用「略過驗證」快速測試，再改嚴格模式。
Q：ServBay 作為伺服器後端做生產穩定嗎？
- A：完全沒問題。大量用戶早已將 ServBay 部署於 Mac mini / Windows 伺服器於 IDC 對外服務。務必設定正確的協定、SNI、Host、憑證信任與 IPv4/IPv6。
Q：沒有公網 IP 怎麼辦？
- A：使用方案一：內建隧道（cloudflared / frpc），無需公網 IP 或埠轉發。

總結

將 ServBay 作為後端源站發布到公網絕對可行。推薦作法是：保留網站的 HTTP & HTTPS 模式，使用前置反代以 HTTPS 回源、正確發送 SNI 並信任 ServBay CA，如此即可獲得端到端加密與 HTTP/2 等現代能力；若沒有公網 IP，則可直接用內建 cloudflared / frpc 隧道最方便；埠轉發僅建議給深諳其風險者。遇到訪問異常時，本文排查清單能助你迅速定位——問題幾乎都出在協定模式、SNI/憑證、Host 標頭、或 IPv4/IPv6。

將 ServBay 網站發布到公網（反向代理、隧道與埠轉發） ​

先理解 ServBay 的預設網路行為 ​

三種發布方式如何選擇 ​

方式一：內建隧道（最簡單，無需公網 IP） ​

方式二：前置反向代理 + HTTPS 回源（推薦） ​

為什麼推薦 HTTPS 回源而非退回 HTTP 80 ​

通用重點 ​

取得 ServBay CA（供反代信任回源憑證） ​

Nginx 反向代理（HTTPS 回源） ​

HAProxy 反向代理（HTTPS 回源） ​

Caddy 反向代理（HTTPS 回源） ​

Traefik 反向代理（HTTPS 回源） ​

方式三：埠轉發（NAT） ​

IPv4 / IPv6 一致性 ​

連線異常排查清單 ​

憑證與安全 ​

常見問題（FAQ） ​

總結 ​