将 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（或跳过校验）即可，无需为回源链路单独申请公网证书。

典型误区：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 — 快速生成临时公网 URL，适合演示、Webhook 联调。

对很多用户来说，用 cloudflared 建一条隧道就足以满足「把本地站点发布到公网」的需求，无需继续阅读后面的反代 / 端口转发方案。

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

这是生产环境推荐的方式：前置反代对外提供公网可信 HTTPS，回源到 ServBay 时也走 HTTPS（保留网站的 HTTP & HTTPS 模式），实现端到端加密。

为什么推荐 HTTPS 回源，而不是退回 HTTP 80

网上大多数教程还停留在「让后端跑 HTTP、反代明文回源」。我们不推荐这种老做法，除非你有极特殊的理由并清楚其代价：

端到端加密：即使反代与 ServBay 在内网之间，流量也全程加密，避免内网嗅探与中间篡改。
现代协议能力：保留 HTTPS 才能让前端顺畅启用 HTTP/2（h2），获得多路复用、头部压缩、连接复用等性能优势；明文 80 会把你锁死在旧范式。
避免降级引发的坑：一旦退回 HTTP，就要和 HTTP & HTTPS 的 301、HSTS 缓存、应用层 https 链接生成等一堆问题缠斗。
信任 ServBay CA 很简单：ServBay 用自签 CA 没有关系——只需在反代侧信任这个 CA，或跳过回源校验，一次配置长期有效。

明文 HTTP 80 方案请见方式三，仅建议给极度有必要、且明确理解其影响的用户。

通用关键点

以下要点适用于全部四种反代，配置示例统一约定：对外域名 example.com、ServBay 后端 192.168.1.115、后端 HTTPS 端口 443、ServBay 网站保持 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 证书文件位于 ServBay 安装目录下：

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 签发。若反代只信任根证书导致回源校验失败，可把根证书与中间证书（同目录下的 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）：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：多数不是「解析不到」，而是 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） ​

总结 ​