Foundry VTT公网访问指南：安全暴露自托管服务的正确方法

从内网自托管到公网访问的转折点

在自托管（self-hosting）社区，一个常见的成长路径是：先在本地网络搭建一堆服务，通过 WireGuard 等 VPN 隧道安全访问，随后因某个特定需求不得不将服务暴露到公网。近期 Reddit 上一位自托管爱好者的提问，正是这一转折的典型缩影。

WireGuard 是一种现代化的 VPN 协议，由 Jason A. Donenfeld 于 2015 年开始开发，2020 年正式合并入 Linux 内核主线（5.6 版本）。与传统的 OpenVPN 或 IPSec 相比，WireGuard 的代码量极小（约 4000 行 C 代码，而 OpenVPN 超过 10 万行），这使得其安全审计更加可行。它采用 Noise 协议框架进行密钥交换，使用 ChaCha20 进行对称加密、Poly1305 进行消息认证、Curve25519 进行密钥协商。WireGuard 的设计哲学是"加密密钥路由"——每个对等节点（peer）拥有一对公私钥，网络接口根据公钥决定数据包的路由去向。对于自托管用户而言，WireGuard 的低延迟和高吞吐量使其成为远程访问家庭服务的理想选择。

这位用户目前运行着约 13 个不同的自托管服务，全部部署在本地网络中，仅通过 WireGuard 在外网访问。他坦言："这样很安全，也完全满足我的需求。"但现在他想搭建 Foundry VTT（一款流行的虚拟桌游平台，用于线上跑团、桌游等），以便与朋友们一起游戏。这意味着服务器必须对其他人开放——Foundry 将成为他唯一暴露在互联网上的服务。

Foundry VTT（Virtual Tabletop）是由 Atropos 开发的自托管虚拟桌游平台，基于 Node.js 和 Electron 构建。它的核心架构采用客户端-服务器模型：服务端运行游戏逻辑和资源管理，客户端（玩家浏览器）通过 WebSocket 保持实时双向通信。这种架构意味着 Foundry 不仅需要 HTTP/HTTPS 端口来提供网页界面，还依赖 WebSocket 长连接来同步地图移动、骰子结果、角色状态等实时数据。默认情况下，Foundry 监听 TCP 30000 端口，同时承载 HTTP 和 WebSocket 流量。其模块系统允许社区开发者扩展功能，但这也意味着第三方模块可能引入额外的安全风险，特别是在公网暴露场景下。

他的第一直觉是：直接做端口转发（Port Forwarding）。但随之而来的疑问是：这样安全吗？应该如何让 Foundry VTT 对公网可连接？

端口转发：最直接但风险最高的方案

端口转发的原理与风险

端口转发是最原始、最直接的公网暴露方式。你在路由器上配置一条规则，将公网 IP 的某个端口（例如 Foundry 默认的 30000）流量转发到内网服务器对应端口。配置简单，几乎所有家用路由器都支持。

从技术原理来看，端口转发的本质是对网络地址转换（NAT）行为的手动干预。在典型的家庭网络中，路由器执行源NAT（SNAT），将内网设备的私有IP地址转换为ISP分配的公网IP。这个过程是单向的——外部主动发起的连接请求会被NAT表丢弃，因为路由器不知道应该将其转发给哪台内网设备。端口转发（也称为目的NAT/DNAT）则是告诉路由器："当公网IP的某个端口收到入站连接时，将其转发到指定内网IP和端口。"这实际上在防火墙上开了一个精确的"孔"。值得注意的是，许多中国大陆的家庭宽带已不再分配真正的公网IPv4地址，而是使用运营商级NAT（CGNAT/NAT444），此时端口转发在技术上就不可行了，这也是隧道方案日益流行的客观原因之一。

但从安全角度看，端口转发存在几个不容忽视的问题：

• 直接暴露真实公网 IP：任何人都能看到你的家庭宽带 IP，为潜在的 DDoS 攻击或针对性扫描提供了目标。
• 应用层漏洞直连：Foundry VTT 本身是一个 Node.js 应用，一旦其存在漏洞，攻击者可以直接触达，缺乏中间防护层。
• 端口扫描无处不在：公网上的自动化扫描器 7×24 小时探测开放端口，暴露的服务很快就会被发现。

关于端口扫描的威胁程度，当一个端口暴露到互联网后，被发现的速度远比大多数人想象的要快。Shodan、Censys、ZoomEye 等搜索引擎持续扫描整个 IPv4 地址空间（约 43 亿个地址），一次全网扫描在带宽充足时仅需数分钟到数小时。此外，大量僵尸网络和自动化攻击工具（如 Mirai 变种）也在不断探测开放端口。根据安全研究机构的统计，一个新暴露的 SSH 端口（22）平均在 20 分钟内就会收到第一次暴力破解尝试。虽然 Foundry VTT 使用的 30000 端口不是常见攻击目标，但非标端口的"隐蔽性"不应被视为安全措施——这只是"安全通过模糊"（security through obscurity），一旦被扫描到，攻击者不会因为端口号非标准就放弃尝试。

如果坚持使用端口转发，至少应做到：只暴露 Foundry 所需的单一端口、配置 HTTPS（通过反向代理加 TLS 证书）、以及保持 Foundry 及底层系统的及时更新。

更安全的替代方案

反向代理 + HTTPS 加密

比裸端口转发更进一步的做法，是在服务器前置一个反向代理（如 Nginx、Caddy 或 Traefik）。反向代理可以统一处理 TLS 加密、请求过滤、限流等，将 Foundry 应用本身隐藏在代理之后。

反向代理位于客户端与后端应用服务器之间，代替后端服务器接收所有外部请求，然后将请求转发给内部服务并返回响应。与正向代理（代表客户端发起请求）不同，反向代理代表的是服务器端。其安全价值体现在多个层面：首先，它隐藏了后端服务的真实地址和技术栈信息；其次，可以在代理层实施请求过滤（拦截恶意负载）、速率限制（防止暴力破解和轻度DDoS）、以及访问控制（基于IP、地理位置或认证）；最后，TLS终止在代理层完成，后端服务只需处理明文HTTP，降低了应用本身的复杂度。Nginx 是最成熟的选择，Caddy 以自动HTTPS著称，而 Traefik 则与容器生态（Docker、Kubernetes）深度集成，能自动发现并代理新部署的容器服务。

Caddy 尤其适合家庭自托管场景，它能自动申请并续期 Let's Encrypt 证书，配置文件极简。用户只需一条反向代理指令，即可让 Foundry 通过 https://foundry.yourdomain.com 安全访问，同时避免明文 HTTP 传输。

Cloudflare Tunnel：零端口暴露方案

如果不希望在路由器上开放任何端口，Cloudflare Tunnel（原 Argo Tunnel）是极受欢迎的选择。它通过在服务器上运行一个轻量客户端，与 Cloudflare 建立出站隧道，从而将服务暴露到公网——全程无需开放入站端口，也不暴露家庭 IP。

Cloudflare Tunnel 的工作原理是"反向连接"模式。传统的服务暴露需要服务器被动等待入站连接，而 Tunnel 则由服务器主动向 Cloudflare 的边缘网络发起出站连接（通过 cloudflared 守护进程）。这个连接使用 HTTP/2 或 QUIC 协议，建立后 Cloudflare 的全球任播（Anycast）网络就成为了服务的入口。当外部用户访问配置好的域名时，请求先到达最近的 Cloudflare 边缘节点，经过其安全检查（DDoS缓解、WAF规则、Bot管理）后，再通过已建立的隧道传递到源服务器。由于整个过程只有出站连接，路由器上无需开放任何入站端口，家庭IP地址对外完全不可见——DNS解析到的是 Cloudflare 的IP。免费套餐即可使用基本的 Tunnel 功能，对于个人自托管场景已经足够。

Cloudflare 还能在其边缘节点提供 DDoS 防护、WAF 规则和访问策略。对于只想让几位朋友连接 Foundry 的场景，这几乎是安全性与易用性的最佳平衡点。类似的方案还有 Tailscale Funnel、frp、ngrok 等。

Tailscale Funnel 是 Tailscale VPN 平台提供的公网暴露功能。Tailscale 本身基于 WireGuard 协议构建了一个覆盖网络（overlay network），为每台设备分配 100.x.x.x 段的稳定内网IP。Funnel 功能则允许将 Tailscale 网络中的服务暴露给非 Tailscale 用户访问。与 Cloudflare Tunnel 类似，它不需要开放入站端口，但流量经由 Tailscale 的中继服务器（DERP servers）转发。frp（Fast Reverse Proxy）是一个开源的内网穿透工具，需要自备一台有公网IP的服务器作为中转节点，灵活性更高但运维成本也更大。ngrok 则提供即开即用的隧道服务，适合临时演示场景，但免费版的随机子域名和连接数限制使其不太适合长期运行的游戏服务。

独立子网与网络隔离

无论采用哪种暴露方式，都建议将这台"对外服务器"与内网其他 12 个服务做网络隔离。可以通过 VLAN、独立子网或将 Foundry 部署在 DMZ 中，确保即使 Foundry 被攻破，攻击者也无法横向移动到其他敏感服务。

VLAN（虚拟局域网）是在二层交换机上通过标签（802.1Q标准）将物理网络划分为多个逻辑广播域的技术。在自托管场景中，可以将对外服务器放在一个独立VLAN中，与存放个人数据的NAS、家庭自动化设备等分属不同VLAN。VLAN间的通信必须经过三层路由器/防火墙，管理员可以精确控制跨VLAN的访问策略。DMZ（非军事区/隔离区）是网络安全中的经典架构概念——将面向公网的服务器放在一个既不完全属于内网也不完全属于外网的中间区域，通常由两道防火墙保护：外层允许公网到DMZ的有限流量，内层严格限制DMZ到内网的通信。即使DMZ中的服务器被攻破，攻击者仍面临第二道防火墙的阻挡。对于家庭用户，许多消费级路由器的"DMZ主机"功能实际上是将所有端口转发给一台设备，与真正的DMZ架构有本质区别，需要注意甄别。

容器化（Docker）部署配合最小权限原则，也能进一步收敛攻击面。Docker 容器利用 Linux 内核的命名空间（namespaces）和控制组（cgroups）机制，为进程提供独立的文件系统视图、网络栈、PID空间等。这意味着即使容器内的应用被攻破，攻击者面对的是一个精简的容器环境，而非完整的宿主机系统。配合最小权限原则：以非root用户运行容器进程、只读挂载不需要写入的卷、使用 --cap-drop ALL 移除不需要的Linux能力（capabilities）、限制容器的网络访问范围（Docker自定义网络），可以显著缩小攻击面。不过需要注意，Docker的隔离不等同于虚拟机级别的硬件虚拟化隔离，内核漏洞仍可能导致容器逃逸，因此容器安全应作为纵深防御中的一层而非唯一依赖。

Foundry VTT 公网部署的实践建议

Foundry VTT 官方文档实际上提供了多种连接方式，值得对照参考：

1. 端口转发 + 域名：官方支持的标准做法，配合动态 DNS 解决家庭 IP 变动问题。动态DNS（DDNS）服务会监控你的公网IP变化，并自动更新DNS记录指向新IP，常见的服务包括 DuckDNS、No-IP 以及 Cloudflare API 自建脚本等。
2. 反向代理部署：官方文档明确支持在 Nginx/Apache 后运行 Foundry，并给出了 WebSocket 转发的配置要点（Foundry 依赖 WebSocket 实时同步游戏状态，这一点在配置代理时容易被忽略）。在 Nginx 中需要正确设置 proxy_set_header Upgrade $http_upgrade 和 proxy_set_header Connection "upgrade" 指令来支持 WebSocket 协议升级，否则实时通信将无法正常工作。
3. 云托管服务：若不想折腾，也可选择 Foundry 官方或第三方的云托管，但这就脱离了自托管的初衷。

对于这位用户的具体情况，考虑到他已经熟悉 WireGuard 且重视安全，Cloudflare Tunnel + Caddy 反向代理的组合可能是最省心的路径：无需改动路由器、不暴露 IP、自动 HTTPS，且能对朋友做访问控制。

总结：安全暴露自托管服务的分层思路

从内网自托管迈向公网服务，本质上是一次"安全边界"的重新划定。这位 Reddit 用户的困惑，代表了无数自托管者都会遇到的门槛。核心原则可以归纳为：

• 能不开端口就不开端口：优先考虑隧道方案（Cloudflare Tunnel、Tailscale Funnel）。
• 必须暴露时做好分层防护：反向代理 + HTTPS + 网络隔离缺一不可。
• 最小化暴露面：只开放必要服务、必要端口，其余继续走 VPN。
• 持续维护：暴露到公网的服务必须保持更新，并监控异常访问。

这些原则实际上体现了信息安全领域的"纵深防御"（Defense in Depth）理念——不依赖单一安全措施，而是构建多层防护，使得任何单一层面的失败都不会导致系统完全被攻破。

端口转发本身不是原罪，但"裸奔"式的端口转发确实不够安全。花一点时间引入反向代理或隧道服务，就能在不牺牲便利性的前提下，让你和朋友们安心地在 Foundry VTT 上开启一场跑团冒险。