科学上网·自建篇（二）：代理协议部署逻辑详解

这篇要讲的是不会过时的部分——部署一个代理节点，无论用哪个协议、哪个内核，背后的逻辑流程是相通的。理解了这套逻辑，你去看任何一篇具体的部署教程，都能知道"这一步在干嘛、为什么这么做"，而不是盲目照抄。

一、 架构总览：自建节点的完整部署逻辑

在动手之前，我们需要理清楚一个现代自建代理节点的核心闭环。盲目复制粘贴一键脚本往往会导致后期排查困难。

自建科学上网节点的完整使用路径：

[客户端 (Shadowrocket/Clash/Sing-box/软路由插件)] 
       │ (TLS/Xray Protocol)
       ▼
[Cloudflare CDN (可选)] 
       │ (WS+CDN)
       ▼
[VPS 完成服务器基础加固]
       │
       ▼
[部署 3x-ui / s-ui 管理面板] ──(API/进程守护)──> [Xray-core 内核]
                                                │
                                       (VLESS / Hysteria 2 / WebSocket...)
                                                │
                                                ▼
                                         [目标互联网服务]

二、一键脚本 vs 纯面板管理：该怎么选

纯一键脚本（如各类裸 Xray 脚本）：

• 优点：极速部署，适合单节点、临时测试。
• 缺点：后期修改配置需重新跑脚本或手动改 JSON，缺乏可视化状态监控，容易产生端口冲突或残留进程。

可视化面板（如 3x-ui / s-ui）：

• 优点：集中管理多用户、多协议、多端口；流量统计直观；支持 Web 端一键续签 SSL；适合长期运维。
• 缺点：多了一层 Web 服务开销（通常占用极少内存），若面板本身未做安全加固（如修改默认端口、开启双重认证），可能成为攻击面。

结论：长期使用，强烈建议使用可视化面板模式。

全网主流的开源科学上网/代理管理面板项目：

如果选择使用一键脚本，安全意识上有几点需要特别提醒：不要无脑执行来源不明的脚本。直接从网络上下载并执行一段脚本，本质上是把服务器的控制权限交给了脚本作者，如果脚本本身包含恶意代码，后果可能是服务器被植入后门、被用作攻击其他目标的跳板，甚至你的数据被窃取。

评估一个脚本是否可信，可以参考以下维度：

即使是知名度较高的脚本项目，也建议保持基本的审慎态度——毕竟脚本执行的是 root 或高权限操作，谨慎总没有坏处。

三、协议选型策略（2026 年现状）

不要盲目堆砌所有协议，现阶段建议采用“推荐组合”策略：

四、 域名、CDN 与 SSL 证书、端口的必要规划

1. 是否有必要规划域名？

• 如果全线使用 VLESS-Reality：完全不需要域名，因为 Reality 借用了别人的证书。
• 如果需要使用 CDN、Websocket 落地、或者 Hysteria 2 的某些前置分流：必须规划域名。建议购买一个便宜的杂牌域名托管在 Cloudflare 上。

2. 脚本自动申请 SSL 证书 vs. Cloudflare API (CF Key) 申请

• 方式 A：脚本基于 80 端口直接申请（Let's Encrypt / acme.sh）
  • 原理：向 Let's Encrypt 证明你对该 IP/域名的控制权（验证 80 端口）。
  • 痛点：若服务器 80 端口被运营商屏蔽、或者被宝塔/其他服务占用，申请会直接失败。
• 方式 B：使用 Cloudflare Global API Key / Token 申请（DNS-01 验证）
  • 原理：通过 DNS 解析记录验证所有权，不需要服务器开放 80 端口。
  • 优势：极度稳定，适合内网穿透或 80 端口受限的 VPS。

3. 核心避坑：套用 Cloudflare CDN 时的证书选择

• 致命误区：很多新手以为套了 CDN 就可以随便用自签证书，或者搞混了“边缘证书”与“源站证书”。
• 正确逻辑：
  • 如果客户端 $\rightarrow$ CDN 开启了代理（小黄云开启），那么 CDN 到客户端使用的是 Cloudflare 的边缘证书。
  • 但 CDN 到你的 VPS（源站） 之间，必须有一套合法的 SSL 证书（可以使用 Cloudflare 免费提供的 15 年长效“Origin Certificate”源站证书）。
  • 如果直接连接节点（不走 CDN 代理，仅 DNS 解析/仅使用 CDN 的加速功能但关闭代理）：必须在面板中使用标准证书（Let's Encrypt），否则客户端 TLS 握手会直接报错。

4. 域名、端口的规划示例（可选，仅参考）

在 《科学上网·资产篇（三）：域名与DNS资产管理指南》，我们提到过，即使你不打算建站，也最好用用一个域名，在自建节点的过程中，合理的对域名进行规划也是非常有必要的。避免使用VLESS、Reality、Hysteria等这种一眼就和科学上网有关的域名前缀，推荐使用 cloud、api、download、static等常用前缀域名。

关于端口规划：如果需要开启 CF 的 CDN（小云朵），必须使用与 Cloudflare 代理兼容的网络端口（官方文档）：443、2053、2083、2087、2096、8443

提示：如果使用 3x-ui 面板，在节点搭建时建议避开 2096，部分版本的 3x-ui 面板默认会占用该端口作为订阅监听端口，具体以你所安装的版本实际情况为准。

• 面板监听域名：建议单独绑定面板监听端口域名，不和节点共用同一域名，并开启CF CDN。
• CF Token 申请 SSL 证书：避免Let's Encrypt / acme.sh 脚本续期证书时出现错误

五、 容易被忽视的隐秘细节：时区、系统时间与 TLS 握手

这是许多老手都会偶尔踩坑、新手排查半天找不到原因的重灾区。这里其实涉及两个完全不同的问题，需要分开理解：一是 VPS 自身系统时间的准确性，会直接影响 TLS 握手；二是本机浏览器时区与出口 IP 地区是否匹配，这是网站用来检测你是否在用代理/VPN 隐藏位置的一种指纹手段，跟 VPS 没有关系。下面分别说明。

VPS 是否需要修改时区？

VPS 的时区显示可以按个人习惯任意设置（UTC 或 Asia/Shanghai 都可以，纯粹是方便自己看日志、排查问题），但真正关键的是系统时钟必须通过 NTP 保持准确同步——时区只是"时间的显示偏移"，不影响底层的绝对时间是否正确。

系统时间（而非时区）对 TLS 握手的影响：

• SSL/TLS 证书具有严格的 Not Before（生效时间） 和 Not After（过期时间） 属性，这两个属性是基于绝对时间（UTC）判断的，与显示的时区无关。
• 如果你的 VPS 硬件时钟（RTC）未同步、或者 NTP 服务异常，导致系统时间落后或超前证书有效期几个小时甚至几天，客户端在进行 TLS 握手时会直接抛出“证书尚未生效”或“证书已过期”的致命错误（例如 x509: certificate has expired or is not yet valid）。
• 修改时区、校准 NTP 同步可参考 科学上网·自建篇（一）：VPS 服务器环境搭建与安全加固 第六步：校准时区与时间同步

需要额外提醒的是，"VPS 系统时间不准导致 TLS 握手失败"，和另一个经常被混淆的场景——"whoer 提示系统时间与 IP 地区不符"——完全是两码事，后者跟 VPS 没有任何关系：

有网友询问过 通过 https://whoer.net/ 检测IP提示：“系统时间不相符 您电脑设定的系统时间不相符您的IP时间区。估计您在试图通过匿名手段隐藏您当前的所在位置。”

这个提示的原理经常被误解——它检测的不是 VPS 的系统时间，而是你正在使用的客户端设备（电脑/手机浏览器）的系统时区设置。

VPS 时区设置对这个检测完全没有影响——VPS 上跑的 3x-ui/Xray 只是转发流量，不会把系统时间"注入"给经过它的 HTTP 请求；浏览器发出请求时用的是本机的 Date/Intl API，与代理链路无关。

如果你要避免这个问题（个人感觉日常使用没必要），真正需要改的是你本机电脑（或浏览器）的系统时区，或者使用指纹浏览器/时区伪装插件。

六、部署后的验证清单

无论前面选用哪种协议组合，节点部署完成后，建议按下面的清单逐项自查，避免"看起来配好了，实际用不了"的情况：

如果连接失败，建议按以下顺序排查：

① 服务端服务是否正常运行
        ↓
② 防火墙端口是否放行
        ↓
③ 客户端配置参数是否与服务端完全一致

按这个顺序自上而下排查，大多数连接失败的问题都能在这三步内定位到原因，避免漫无目的地反复改配置。