Web Station 建站与反向代理

套件在干什么

Web Station 是群晖的 Web 服务器套件：装上之后 NAS 就能托管网站，支持 Apache、Nginx 和 PHP，配合 MariaDB 数据库套件可以跑完整的动态站点。除了建站，它还有一个更常用的隐藏角色——所有 Web 套件和网页服务背后的底座。理解反向代理之前的铺垫是：DSM 自己的网页服务、各套件的网页入口，都是同一套 Web 技术实现的。

反向代理（reverse proxy）是本篇真正的主角。普通端口转发是把外网端口一对一地打到内网服务上，反代则是「一个域名入口分发到多个内部服务」：浏览器请求 https://app1.你的域名，反代服务器根据域名把它转发到 NAS 本地的 8096 端口；请求 https://app2.你的域名 转发到另一个端口。对外只露一个 443，对内想挂多少服务都行。

反代的好处一箭三雕：统一 HTTPS 证书、统一端口入口、统一访问控制。家用场景里它把「NAS 服务的访问体验」从地下车库拉到写字楼大堂。网络概念不太熟的可以先补 DNS 和端口的基础，参考 计算机网络基础。

Web Station 建一个静态站

先把 Web Station 本职工作跑通。套件中心安装 Web Station 和 PHP（依需版本），它会自动建一个 web 共享文件夹。把静态网页（HTML 一类的文件）丢进 web 目录，浏览器访问 NAS的IP/文件夹名 就能看到。这就是一台完整功能的 Web 服务器，连数据库都不用。个人作品集、家庭公告页、工具书签页，几个 HTML 文件的事，零成本上线。

默认虚拟主机设置里能调 PHP 版本和默认文档（index.html 的优先级）。虚拟主机（Virtual Host）是 Web Station 的进阶能力：给站点绑定域名、指定根目录。一个 NAS 能同时挂多个站点，各自独立根目录、独立 PHP 配置。配合反代对外映射，每个站点有自己的访问入口。

想跑博客（WordPress 一类）的话：建 MariaDB 数据库和用户、WordPress 文件解压到 web/wordpress、跑安装向导。数据库的密码和库名在 MariaDB 套件里建，记好笔记，安装向导要填。这套流程能把 NAS 变成小型博客主机，配合反代加证书还能发布到公网。个人博客是 NAS 玩家最常见的建站练手项目，整个流程半小时走完，维护成本低，内容完全自主。

注意套件版本和 PHP 版本的匹配：不同应用要的 PHP 版本不同，Web Station 里能给每个站点单独指定 PHP 版本。装好之后站点列表会列出全部站点，指定根目录和 PHP 配置一目了然。

反向代理的配置

真正的重头戏在控制面板里：登录门户、高级、反向代理服务器。点新增填一条规则，就能把一个域名入口转到任意端口上。一套家用反代系统通常建三四条规则：DSM 界面留给内网不建规则，影音、下载、笔记各一条，每条规则的来源主机名就是各自的子域名。

启用 HSTS 强制 HTTPS，启用访问控制可以按 IP 段限制来源。规则建好之后，路由器只需要把 443 转发到 NAS，所有服务共用这一个入口。每条规则对应一个子域名，DNS 里把每个子域名都解析到公网 IP（或者泛解析一次解决）。泛解析（星号记录指向公网 IP）加一条就能用任意子域名，最省事；谨慎起见的同学逐条解析也行，规矩但啰嗦。子域名命名建议成体系（media、dl、note 一眼可辨），半年后加新服务也不会撞名。

容器服务挂反代时，目的地主机名有个讲究：容器用 host 网络或者端口映射到本地，填 localhost 没问题；容器跑在自定义网桥上，填容器 IP 会更直接，但容器重建 IP 会变，稳妥的做法是给容器固定 IP 或者用本地映射端口。WebSocket 类应用（比如面板类工具）要在自定义规则里加上 Upgrade 头的支持，否则实时刷新的功能会失灵，这是反代最常见的玄学故障。

证书：Let‘s Encrypt 免费方案

反代配 HTTPS 必须要证书，DSM 内置了 Let‘s Encrypt 免费证书申请。控制面板、安全性、证书、新增，选「从 Let‘s Encrypt 获取证书」，填域名和邮箱，前提是域名已经解析到你的公网 IP 且 80 端口能从外面访问（验证要走 80 端口）。几分钟之后证书就下发到证书列表，绑定到对应反代规则的来源主机名即可。

申请前检查三件事：DNS 解析已生效、80 端口在防火墙放行、DSM 页面（HTTP 端口）能正常打开。验证失败十有八九是这三环之一。Let‘s Encrypt 三个月一换，续期由 DSM 自动处理，快到期的前几天通知中心会提醒续期结果，留意一下。

有泛域名需求的可以申请通配证书，DSM 的 ACME 界面对泛域名验证（DNS 验证）支持有限，用脚本工具（acme.sh 一类）配合计划任务也能完成，这就属于进阶玩家自己琢磨的范畴了。

这套架构的日常维护

反代加证书跑起来之后，日常维护做四件事：证书到期前看通知、DSM 更新后检查反代规则还在、新加服务先内网测通再挂反代、访问日志定期看一眼。反代规则在 DSM 大版本更新时偶尔会出兼容问题，升级前截图存一份规则列表，出问题能照着重建。

安全方面，反代统一入口之后攻击面集中在一个 443 上，这个端口的防护标准要拉高：强密码、两步验证、登录失败锁定。反代的访问控制规则建议默认拒绝，只放行已知 IP 段，比裸奔安全得多。DSM 管理界面绝不要走公网反代，影音和工具类服务足够了。

什么服务适合挂到反代后面

反代虽好，不是所有服务都该挂上去。适合挂的是这两类：有完整登录认证体系的 Web 应用（影音、下载、笔记的面板）、纯静态内容（个人博客、导航页）。不适合挂的是两类：DSM 管理界面本身（把它暴露到公网等于把家门钥匙挂门外）、没有认证机制的工具面板（监控、数据库管理这类，谁打开都能操作）。

没有认证的服务又想外网用，标准的替代方案是走 VPN 而不是开反代：整个人连进内网再访问，安全性高一个量级。实在想挂的最低限度补救：反代规则里开访问控制、只放行自己的 IP 段，或者在服务前面加一层网关认证。这些权衡以后在安全章节展开。

挂反代的服务还有一处要注意：部分应用里写的内部跳转链接会带端口号，经过反代之后端口号错位。应用有「反向代理」或者「外部地址」设置项的，填上反代域名，应用生成的链接就都是正确的域名形式。Jellyfin 的 JELLYFIN_PublishedServerUrl 就是干这个的。

日志与排错

反代出问题排噪顺序：先换浏览器隐身模式排除缓存；再看证书是否有效（地址栏小锁有没有感叹号）；然后看规则目的地端口通不通（内网直接访问服务 IP 加端口验证）；最后看服务本身有没有启动。四步走完，95% 的反代故障都能定位。

DSM 自己不直接给反代访问日志，想看请求记录的可以在日志中心里翻相关条目，关键字搜「反向代理」。高级玩家也可以在容器里跑一个独立的反代（Nginx 一类）代替 DSM 内置方案，请求日志和自定义头都自由，代价是证书要自己配。两条路各有受众，家用体量内置方案完全够。把反代的来源、域名、目的地端口写成一张表贴在配置旁边，半年后回头改规则就不用重新推理。

延伸阅读

• HTTPS 证书与域名配置：证书与域名的完整方案与续期维护
• 计算机网络基础：DNS 与反向代理的原理
• 防火墙规则与端口管理：入口收敛之后的防火墙策略