「自建」两个字听起来像是一个动作，实际上它至少包含三个独立的决定：这台服务器归谁管、用哪种协议、以及哪些流量应该走隧道。三者相互关联，但不能互相替代——服务器是自己的，不代表配置就安全；协议选对了，也不代表分流规则合理。
这篇把这三层拆开说明，并补上一个常被跳过的问题：自建之后，长期的维护责任由谁承担。
先分清三件不同的事
官方 README 描述了客户端在用户自己的服务器上部署服务端的路径，并列出多种协议。部署在自有服务器、选择某个协议、以及决定哪些应用走隧道，是相互关联但不能互相替代的决策。输入 SSH 信息前，先确认服务器归属、系统维护责任和账户权限；不要把临时可登录误当成长期可维护。
建议的操作顺序
- 从官方文档或官方 Releases 进入客户端安装页，核对发布者、平台与版本。
- 在非关键服务器上阅读部署说明，确认自己理解 SSH 账号、容器安装和后续更新分别由谁负责。
- 选择协议时只记录官方文档所述能力，不把“伪装”“混淆”等表述改写为必然有效的规避承诺。
- 需要 Split Tunneling 时，先明确哪些网站或应用应走 VPN、哪些应保留本地网络；官方说明称按应用分流支持 Android 与桌面端，实际表现仍要在自己的设备验证。
维护责任是自建的真实成本
部署那天通常最顺利：文档跟着走，一小时内就能连上。真正的成本出现在之后——系统需要打补丁、证书需要续期、服务需要在重启后自动恢复、账单需要有人盯着。这些事没人提醒你，但任何一项出问题，服务就停了。
所以在决定自建之前，值得先诚实地回答一个问题：三个月后，还会有人管这台机器吗？如果答案不确定，那么用一个成熟的服务，可能比自建一个无人维护的更可靠。这不是能力问题，而是持续投入的问题。
分流规则怎么设计才不容易出错
- 先列出必须走隧道的：通常是少数几个明确的目标，而不是「除了本地都走」。
- 再列出必须直连的：局域网设备、本地服务、以及某些对网络位置敏感的应用。
- 其余的定一个默认：默认走哪边，取决于你的主要用途。
- 逐条验证：每加一条规则就验证一次，不要一次写十条再统一测。
- 把规则和理由记在一起：几周后你会需要这些理由。
三层判断的常见误配
把「服务器是我的」当成「配置是安全的」。所有权解决的是控制权问题，配置是否合理、系统是否及时更新，仍然要单独做。
把协议名称当成效果承诺。官方文档描述的是机制，实际表现取决于网络环境与运营状况，两者之间没有必然联系。
把分流当成一次性设置。应用会更新、需求会变化，几个月前写的规则未必还适用。定期回看一次分流规则，比出问题时临时排查省事。
这三条误配的共同点，是把不同层次的结论混着用。拆开之后，每一层该做什么其实都很清楚。
部署前的自查清单
- 这台服务器归谁所有？谁有管理权限？
- 系统更新与安全补丁由谁负责、多久一次？
- 重启之后服务能自动恢复吗？我验证过吗？
- 分流规则里，哪些是必须直连的？
- 如果我不再维护它，怎样安全地下线？
常见问题
自建是不是一定更安全？
它改变的是控制权归属。安全性取决于你怎么配置、怎么维护，以及服务器本身所处的环境，不会因为「自己的」而自动提升。
需要多强的服务器？
个人使用通常对配置要求不高，瓶颈更多在带宽与线路而不是 CPU。先从小规格开始，不够用再调整。
协议选哪个？
先按官方文档所述的能力与你的客户端支持范围来定，不要把「混淆」「伪装」这类描述理解成必然有效的承诺。
能不能让家人也用同一台服务器？
技术上可以，但要先想清楚凭据怎么分发、出问题谁来处理。多人使用会把「维护责任」这件事从可选变成必须。
文档写得不全怎么办？
把没写清楚的部分当作未知，而不是默认它按你期望的方式工作。在非关键环境里先验证一次，比上线后再发现差异代价小得多。
下线时该做什么？
撤销所有凭据、删除服务器上的数据、确认账单已停止。只关掉客户端不算下线，服务器仍在运行并可能继续计费。
部署完成后还需要做什么？
至少三件：确认自动更新或补丁策略、验证重启后服务能恢复、设定一个定期检查账单与到期日的提醒。
要不要同时保留一个商业服务？
值得。自建出问题时你需要另一条路来查资料和恢复，判断独立性的方法见不要把「同类入口」误当作备用方案。
