1 前言

自从购买了Racknerd的VPS，并完成了将容灾节点从腾讯云轻量服务器搬家到Racknerd芝加哥VPS的大工程之后(参见文章：家庭数据中心系列 博客架构的第二次重构：VPS搬家引发的服务迁移与双活容灾实践，数据中心搬家可不就是大工程)，我还在思考如何能够充分利用这高价购买(39.88美金/年)的芝加哥节点(Racknerd_高配1_882)，毕竟现在芝加哥节点的资源还大量闲置着：

转念一想，其实除了硬件资源，芝加哥节点每月流量高达8500G，而我现在主要是将它作为平时核心应用(博客)对Cloudflare的主回源站，这种用法根本用不了多少流量，等于说这么多月流量完全浪费了。

既然想充分利用流量，那自建科学节点就是首当其冲的用法了。可是因为我之前并没有境外的VPS，对这方面的知识也不怎么了解，所以，需要先梳理一下相关的知识点。

2 背景知识：现实网络环境下的访问困境

在当今的网络环境中，连接并不总是”通的”：某些网站明明在线，页面却打不开；一些软件默认配置正确，却无法正常使用；一些域名无法通过公共 DNS 正确解析；浏览器内置的加密 DNS（如 DoH 或 DoQ）无法正常启用……诸如此类的问题时有发生，原因常常不是服务端的故障，而是通信路径中存在一堵透明的”wall”。

在某些区域的网络中，出于内容合规、信息监管、数据审计等目的，运营商会对目标指向境外的通信数据进行智能识别与策略拦截。这类行为背后依赖的是一整套被称为深度包检测（Deep Packet Inspection, DPI）的机制，它并不需要解密内容本身，而是通过分析加密协议的握手元数据（如 TLS 的 SNI、JA3 指纹，QUIC 的初始数据包结构等），来对流量进行特征化识别，再基于匹配结果动态决定是否放行，这些干预行为都来自透明的”wall”。

值得注意的是，这类干预并不针对某一个具体协议、服务或应用，而是建立在”通信行为模式”的识别与封锁之上。这种策略天然带有不确定性，常常因出口链路不同、路径节点策略更新、服务部署方式变化而出现”时通时断”、”部分服务异常”的情况。于是，我们所面对的，不再是一个稳定的网络传输模型，而是一个充满变量的、动态博弈的现实环境。

举个简单的例子：你在浏览器中启用了”安全 DNS”功能（如 Cloudflare 或 Google 的 DoH），本意是提升解析隐私性和完整性，却可能在 TLS 握手阶段就被网络中间节点重置连接，导致”域名无法解析”甚至”网页无法打开”；又如，一些用户访问开发者社区网站（如 GitHub、Docker Hub、Stack Overflow 等）时，会遇到偶发的连接异常，这种现象既不容易排查，也缺乏规律可循。

对普通用户而言，这可能只是”偶尔打不开某个网站”——他们可以选择换个内容、避开问题；但对于技术用户、跨境办公者、自建服务的开发者来说，这背后带来的挑战是更深层次的：连接的不可预期性与通信的结构性不确定性。在这种背景下，如果仍然使用传统的”直接访问”模式来进行通信，那么，需要与境外服务器通信的朋友会变得举步维艰。

如何解决呢？最常见的方式，就是借助科学上网，通过构建一条绕开干预路径的”通信隧道”，从而避免访问境外内容时被透明的”wall”干扰。

目前，科学上网的方式大致可以分为两类：

第一类，是使用第三方提供的付费服务。

这类服务的特点是 “开箱即用” ：用户只需购买账号、订阅配置，即可一键连接境外节点，无需关心底层协议、回源机制或流量分流等技术细节。它几乎是最省事的方案，门槛低、体验直观，深受新手用户欢迎。但与此同时，这种方案也存在一定的隐患：

• 一些廉价服务提供者的”跑路”现象屡见不鲜，用户资产和数据安全无法保障；
• 只是”跑路”还好，如果遇到官方主导的”钓鱼”类提供商，嘿嘿；
• 某些高端服务虽稳定但价格昂贵，长期使用成本较高；

第二类，则是自行搭建科学上网节点。

这种方式的核心在于：你拥有一个可控的境外 VPS，自己部署服务端程序（如 sing-box、xray、trojan-go 等），并自行管理连接协议与策略，这条路径的优势是明显的：

• 可自由选择协议类型、加密方式和传输路径，规避主流服务的流量特征；
• 可以按需部署多个节点、集成中转、接入 tunnel/CDN 等手段，实现更高的抗封锁性与灵活性；
• 成本上更具可控性：一般的VPS自带的月流量足够满足多人使用

但它的劣势同样明显：

• 需要有基础的网络知识，了解 VPS 管理、域名解析、证书申请等相关操作；
• 需要自行应对透明”wall”的策略更新，动态调整部署方式、协议配置与节点架构；
• 还需应对偶发的 IP 封锁、证书吊销、域名污染等问题，具备一定的故障排查能力。

因此，自建科学服务节点与使用第三方提供科学服务之间的选择，往往取决于用户对稳定性、安全性、成本与控制力的权衡。而本文的重点，也正是在于帮助有一定动手能力、希望构建更可靠通信环境的用户，理解并掌握”自建科学节点”的核心原则与演进方式。

本文不涉及”使用第三方提供科学服务”方面的内容，只谈谈为了学习和工作需要如何利用已有的境外VPS自建科学服务节点。总的来说，自行搭建科学上网节点有两大类选择：直连和非直连，这两种选择各有优劣势。

3 直连模式：源站直接暴露的科学方案

3.1 穿越透明的”wall”：直连模式的天然难题

在科学访问的场景中，所谓”直连模式”，并不是指用户直接访问目标网站，而是指用户通过一条自己建立的、与自己可控可信的境外 VPS 之间的通信链路，将后续的访问请求转交给境外 VPS，由它代为转发。这实际上可以拆解为两个关键阶段：

1. 连接阶段：从本地设备直连境外 VPS，建立一条穿越透明的”wall”的通信通道；
2. 转发阶段：把对目标网站、服务的访问请求发给境外 VPS，由它代为发出请求并将响应内容返回。

第二阶段容易实现，但是作为关键的第一阶段”连接阶段”却很困难：如何顺利”穿过”透明的”wall”？

3.2 连接阶段：能不能连上 VPS？

在国内网络环境下，客户端要想直接连接境外 VPS(通常是某个云服务上的公网 IP)，必须经历一段”不可预测”的出境路径。在这个路径上，存在一种无形的机制，会对跨境流量进行实时筛查、判断和处理：你要连的服务是什么？协议看起来像不像 HTTPS？是不是最近在”滥用”这段链路？是否触发了既定规则？

这一机制表面无形，实则运行在骨干出口路由、运营商边缘网关等关键节点上，依赖的手段主要包括：

• 深度包检测（DPI）：在 TLS 握手阶段分析 SNI 字段、JA3 指纹、ALPN 协议标志等，识别服务端类型与通信意图；
• 行为模式匹配：针对非标准协议（如伪装 HTTPS 的代理、QUIC 或 DoH）的行为建立特征库，进行投射性阻断；
• 路径压力监测：如果某段出口频繁出现非浏览器式连接请求，也可能被动态限速、重置连接、直接丢包。

这意味着：哪怕你把 VPS 的服务监听在 443 端口，使用 TLS 协议包裹通信内容，也不等于一定可以顺利连上；即便连上，也不等于一定稳定。

协议与端口：影响直连通行率的”形态特征”

在面对中间设备的策略识别时，通信协议的类型和使用的端口组合会直接影响数据包是否顺利穿越。透明的”wall”不会明说”封了谁”，但会在行为上对某些特征更敏感、更容易干扰。以下是目前网络环境中较常见的”放行优先级”：

• TCP 443 端口（HTTPS）
  这是现代加密通信的主流端口，浏览器访问、系统更新、移动应用后台等大量流量都走这条路径。出于避免误伤合规通信的考虑，策略系统往往对 443 上的流量更为克制，具备最高”放行优先级”。因此，许多科学协议会主动”借壳”使用 443 端口来提高伪装性。
• TCP 80 端口（HTTP）
  明文协议，但依然被广泛用于各类低安全要求的服务。尽管加密程度低，但由于使用普遍，也具备一定的”放行基础”。不过因为是明文，容易被完全解析，适合做混淆而不适合承载敏感流量本身。
• UDP 协议整体处于”高敏感区”
  与 TCP 不同，UDP 是无连接、无状态的，天生更适合高速传输和即时通信，但也更容易被滥用。策略系统对 UDP 的默认策略通常更为激进，常见表现为：
  • QUIC（HTTP/3）：明确基于 UDP，访问 Google、YouTube 等服务时常被用于提升性能。但也因其行为特征明显、启用初始握手明显，常常遭遇连接失败或降级回 TCP。
  • WireGuard / OpenVPN（UDP 模式）：早期是自建科学节点的主力，但这些协议握手固定、特征明显、指纹独特，已被 DPI 系统广泛掌握，导致容易被秒断、延迟高、稳定性差。
  • Hysteria / TUIC 等新兴高性能隧道协议：虽然在 UDP 上传输，但设计上更强调防识别、防阻断能力，在一定程度上更具”抗扰动”属性，但仍需看实际部署方式与路径条件。
• “混合协议”或”TCP 协议模拟 UDP”
  一些工具（如 Trojan-Go）虽然主要基于 TCP，但可以选配启用 UDP 转发功能。这种模式在策略判断上表现不一：未启用时相对安全，启用后则可能触发更多干扰。
• DoH（DNS over HTTPS）
  实际是 DNS 查询通过 HTTPS 封装后的变体，走 TCP 443 端口。但因为其”非典型 HTTPS”行为（如极短的握手和小包交换），在部分路径上仍可能被判定为异常通信而被阻断。

因此，不能只看协议名或工具名称，还要关注其运行模式、使用端口、是否走 UDP、是否有典型握手特征等多个维度。真正影响穿越成功率的，不是”用什么协议”，而是你的协议行为是否”足够正常”、是否被透明的”wall”当作”应该放行的流量”。

3.3 常规流量伪装方案也未必把稳

为了通过第一阶段，市面上出现了很多”协议伪装”型方案，它们的核心思想是：让你的流量看起来就像是个普通人打开了一个网页(http + tls)。以下是不同协议的伪装方案对比：

这些方案在刚出现时确实能带来一些突破，但后续的缺点也很现实：

• 流量特征稳定，协议 fingerprint 被逐渐摸透，尤其如 Trojan 等协议，已有多年未更新，特征鲜明；
• DNS 污染、TLS Reset、主动探测（如探测回包行为）等干扰手段频繁命中；
• 即便开启 TLS，SNI(Server Name Indication)仍为明文，可被利用；
• 伪装策略多数依赖 HTTP Host Header 或流量 padding，在复杂 DPI 面前越来越脆弱。
• 源站 IP和服务端口长期暴露，易被探测与封禁；

3.4 别误会，连上 VPS ≠ 科学上网成功

需要强调的是，连上了境外 VPS，仅仅是科学访问的起点。科学上网的核心在于：能否通过 VPS 顺利访问境外被限制的资源，并把响应安全地带回本地。

而这一过程也同样受到各种干扰：

• VPS本身访问外网资源的路径是否可靠？比如访问 Google、YouTube、GitHub 时是否也被限制？
• 数据包是否因”流量特征异常”而在中途遭遇 reset？比如，明明只是打开一个普通网页，但页面加载过程中连接突然传回大量数据、长时间占用带宽，这种”行为与期望不符”的情况，可能会被识别系统视为”可疑通信”，进而通过发送 RST 来强行终止连接。
• 整体链路是否具备足够的稳定性和隐蔽性？比如，有些朋友配置了基于 Hysteria 或 WireGuard 的节点，测速时表现极佳，但一到实际使用时却频繁断流，甚至连接直接被重置。这往往不是 VPS 本身的问题，而是链路在穿越某些关键路由段时被检测出异常，遭到策略性干扰——例如握手特征异常、数据包突变、流量行为”不够自然”等，都会成为触发点。

这就是直连模式的天然限制：它太依赖”直接通信”，也太容易暴露目标。

注1：通常使用”直连”方式来搭建科学服务，一个潜在的要求就是直接访问 VPS 时的延迟。因此，节点的物理位置选择变得尤为重要——你不仅要考虑带宽、价格和地区，更需要考虑从你所在地出发的链路质量。否则，即使搭好了节点，客户端也会因为高延迟或丢包严重而得不到良好的使用体验。此外，”直连”方案也意味着服务端真实 IP 会直接暴露在公网之中，如果这个 IP 所属网络的抗干扰能力较差、运营商较小众、或行为模式过于”明显”，也很容易被精准识别并遭遇封锁，所以通常要求服务端VPS采用”精品线路”。这正是很多人开始考虑”非直连”方案的根源之一：不是直连不好，而是”直接暴露”在今天的环境下不够稳定、不够持久。

注2：尽管”直连 + TLS”本身已经具备一定的加密性，但这在当前的检测环境下往往还不够。所以，我们可以借助 Nginx、Caddy、HAProxy 等支持反向代理的中间层，在 VPS 上再”包一层正常 Web 流量的壳”，比如同时运行一个博客、CDN 缓存站，或返回一个静态网页响应，以此混淆流量特征，提高”看起来像正常 HTTPS 网站”的程度。这类”多层伪装”虽然不能完全避免识别，但能显著增加被动干扰时的容错性和稳定性。

注3：当然，不是说“直连”模式就不能用，毕竟目前采用“直连”模式自建科学节点的用户仍占了相当的比例。很多人依赖其配置简单、延迟低的特点，尤其是在早期节点不受限制或特定地区仍有较好效果的情况下，它依然是许多人的首选方案。但从趋势上来看，这种模式面临的困难会越来越大：一方面，运营商和平台对加密流量的识别与干扰手段在持续进化，简单的直连方式更容易被探测、限速甚至封禁；另一方面，越来越多的服务需要在抗审查性、稳定性和隐蔽性之间寻求更平衡的方案，这就意味着采用更复杂的架构，比如中转、隧道封装、异地分流等方式，将逐渐成为主流。

4 非直连模式：借助中转入口隐藏源站 IP

4.1 为什么需要”非直连”？

在”科学上网”的早期阶段，直连模式是一种看似简单直接的方式：只要将客户端连接到境外 VPS，通过一条受控通道转发请求，就能访问外部互联网。然而，这条”看似打通”的路径，实际上极为脆弱：一旦境外 VPS 的 IP 地址暴露在国内网络中，它就可能成为 DPI（深度包检测）系统、行为识别模型、关键字监听系统的重点关注对象。一旦被标记，连接会出现如下问题：

• 流量被限速、注入干扰、甚至直接 reset；
• VPS IP 被加入阻断名单，连接完全中断；
• 跨境通信”阶段性死亡”，但无明确错误信息，难以定位问题来源。

问题的核心：透明的”wall”并非针对某一个服务或站点，而是试图识别”异常的连接行为”。而当一个境外 VPS 被数十个客户端以相同方式访问，流量特征固定、访问频率异常时，这个 VPS 的”身份”就不再是一个普通 Web 服务器，而是一个可疑通信中转点。

在这种背景下，继续坚持”直连”的策略，就意味着：

• 不断更换 VPS；
• 随时应对连接不稳定；
• 每一位用户都要承担连接失败、流量被封的高风险。

而更根本的问题在于：如果用户的请求每次都直接指向目标服务的真实地址，那么服务端”藏不住”，识别系统永远有发挥空间。

4.2 “非直连”实现的关键：中转入口

事实上，非直连模式真正的意义，是让”源站”IP不再暴露在公网之下，这就需要配合中转入口使用。真正意义上的”非直连”方案，应该是这样一条链路：国内客户端──连接──> 中转入口 ──转发──> 真实 VPS / 源站服务。这种设计下，对于透明的”wall”而言，看到的永远是国内客户端在访问中转入口，至于对中转入口背后的源站，那是一无所知的。

如何寻找”中转入口”？

要能在今天的网络环境中作为一个”中转入口”，不是随便找台机器就能胜任的，它必须满足以下几个关键条件：

• IP 不会轻易被封杀：最好是大厂出身的 IP，具备”可信背景”，不会因为一点”非典型流量”就立刻遭到封锁
• 具备一定中立性：比如 CDN、分布式网络平台，墙对它们天然更”温和”，不会轻易出手
• 支持自定义流量转发：比如能建立反向隧道、WebSocket 转发、或者直接 TCP/QUIC 转发的能力

这些条件组合在一起，实际上已经排除了绝大多数个人服务器或便宜的商用 VPS ：你要的不是”谁都能部署”的跳板，而是一个不会轻易出问题的”伪装点”。

现实中，中转入口的优选对象：Cloudflare，因为它恰好具备上述所有特质，这使得其本身成为一个极具潜力的中转入口：

• IP 稳定且信誉极高：其网络节点广泛服务全球百万网站，是现代 Web 世界的”基础设施”；
• 天然 CDN 平台：墙对 CDN 的策略处理更为克制，往往优先保障”可用性”；
• 支持灵活的反向代理逻辑：通过自家的入口网络，把公网流量中继回你的真实服务。

4.3 前置知识：Cloudflare反向代理功能的实现方式

当利用 Cloudflare 来构建”非直连”的中转入口时，真正发挥作用的，并不是它作为 CDN 的传统功能，而是它覆盖全球的边缘网络以及高度灵活的反向代理能力，所以需要先了解其提供的”反代”方式。

从整体机制上看，Cloudflare 提供了两种典型的”反代”方式：

1. 公网回源（Public IP 回源）

在这种模式下，Cloudflare 作为边缘代理，仅仅转发来自客户端的请求，然后通过 DNS 指向你配置的 公网服务器 IP，回源取回内容。虽然部署简单，但也暴露了一个致命问题：你的真实服务器 IP 必须是公网可见的，而这恰恰是”非直连”想要规避的点。

2. Cloudflare Tunnel（内网穿透式反代）

这是我们重点关注的方式：Tunnel 由你自己在服务端启动，主动向 Cloudflare 发起连接，创建出一个反向通道，让 Cloudflare 能够将用户请求安全地转发到内网/非公网 IP 的服务上。整个过程中，无需暴露源站 IP，也不需要开放任何公网端口。

从隐蔽性、安全性和可生存性来看，Tunnel 模式显然更符合”非直连”的设计目标：

• 源站 IP 永远不会暴露在 DNS、扫描器或直连测试中；
• 整个链路由内而外建立，避开传统连接方式所面临的干扰和封锁；
• 即便服务部署在家宽、NAT 内网甚至 IPv6-only 环境下，也能轻松连通。

因此，在当前复杂网络环境下，Cloudflare Tunnel 已经成为”非直连”模式的主流实现方式之一，尤其适合搭配自建代理服务共同使用。

4.4 “非直连”的代价与限制

在上一节中我们提到：Cloudflare Tunnel 已经成为”非直连”模式的主流实现方式之一，它隐藏了真实源站的 IP，只暴露 Cloudflare 的边缘节点，让很多自建方案在今天的环境中得以继续存活。

但遗憾的是，如果你想将现有的代理服务”无缝接入” Cloudflare Tunnel，会发现并非所有协议都能用——Tunnel 并不等于”万能反代”，它支持的只是极少数能够”顺利伪装”的协议栈。 这是因为Cloudflare Tunnel 的设计初衷是服务于 Web 应用，它默认期望你提供的是一个标准的 HTTP 或 HTTPS 服务，同时也在防着你乱用。这也就意味着：只有那些本身就”长得像 HTTP 服务”的代理协议，才有可能被 Tunnel 顺利接入并成功传输。 典型代表是 Trojan 和 VLESS ——它们本身就强调通过 TLS、WebSocket 等方式”伪装为浏览器访问”，而这刚好符合 Cloudflare 的流量策略。

因此，如果你要将代理协议通过 Tunnel 进行中转，推荐的组合是：

WebSocket 是什么？为什么我们需要它？

WebSocket 是一种运行在 HTTP 协议之上的”持久连接”机制，它的设计初衷是为了在 Web 页面和服务器之间建立一个可以双向实时通信的管道，它的魔力在于：

• 初始握手阶段看起来就是一个标准的 HTTPS 请求（这点对”伪装”至关重要）；

• 成功建立连接后，可以在这个看似普通的”网页通道”里，传输任意类型的数据——包括我们要走的代理流量。

  对于 Cloudflare Tunnel 而言，它默认期望代理的是网站请求，所以若想”偷偷”塞进其他非标准流量，就必须先把这些代理协议封装进 WebSocket，才能伪装成合规流量绕过检测。 这也是为什么 Trojan、VLESS 等协议往往推荐搭配 WebSocket：不仅能伪装得更像网站访问，还能穿过 Cloudflare Tunnel 的”Web 审查”。

4.5 “非直连”科学节点速度是否一定比”直连”科学节点慢？

这是很多自建用户心中的疑问，甚至是误区。直觉上，“非直连”方案在链路上绕了一道弯，必然导致性能下降。但事实是，这个判断在当下的网络环境中并不成立，甚至很多时候恰恰相反——“非直连”反而更快、更稳。 原因主要有以下几点：

1、直连≠畅通，很多时候是”被识别后不断阻断”

“直连”科学节点最大的问题，不在于带宽，而在于流量是否被完整、稳定地送达目标 VPS。现实中，很多所谓的”直连”连接并不是真正意义上的”畅通”：

• 数据包被中途丢弃（Drop）或主动重置（RST）；
• 连接建立后能通信，但速度极慢、不稳定；
• 某些时间段突然无法连接，之后又神奇恢复。

这类现象并不罕见，背后反映的其实是链路并不可信。所以很多”直连”的速度慢，根本原因不是走了直通路线，而是这条路线根本不欢迎你。

2、“非直连”通过中转规避了流量识别，提高了整体链路质量

相比之下，”非直连”通过中转入口隐藏了真实源站，让链路前半段的流量看起来像是访问一个常规服务（比如 Cloudflare 节点、知名云厂商 IP、CDN 分发中心等），从而在接入侧获得了 更高的链路容错率与稳定性。

而且，中转入口与源站之间一般走的是标准国际线路，且不受中间干预，这段链路质量往往比”直连穿墙”要高得多。

3、延迟与吞吐并非只有”路径短”这一影响因子

很多人误以为”路径越短，延迟越低”，但在当下网络环境中：

• 路径是否被限速、干扰、压制
• 源站所在机房的出口质量
• 中转服务器的吞吐瓶颈
• 协议的连接恢复/重传效率

这些因素往往比路径长度更关键。比如一个”直连”VPS位于亚洲小机房，但出口糟糕、TCP handshake 频繁失败；而一个”非直连”VPS虽然绕路走了 Cloudflare Tunnel，但出口是 GCP、Azure 等优质大厂线路，反而稳定、快速得多。

4、“非直连”还可以轻松构建多点中转、负载均衡、故障转移等机制

这是”直连”模式难以实现的：一旦节点被识别、封锁，整个方案失效。而”非直连”由于天然具备灵活的入口配置和协议伪装能力，非常适合构建多链路并行、动态切换等更具工程弹性的架构。

结论：“非直连”不是”退而求其次”，而是在现代网络环境下更具隐蔽性、抗干扰性和扩展性的现实选择。其表现是否比”直连”慢，并不取决于”走没走直线”，而取决于链路整体的安全性、隐蔽性与调度能力。

4.6 Cloudflare Tunnel 与科学用途的合规性问题

虽然 Cloudflare Tunnel 几乎天生就是”非直连”模式的理想工具 —— 它稳定、全球分布广泛、不需要暴露公网 IP，还能无缝配合 VLESS/Trojan 等协议完成 TLS + WebSocket 的完整伪装链路 —— 但这里必须郑重提醒一点：Cloudflare 明确禁止将其服务用于代理、VPN、科学上网等用途。

Cloudflare的服务条款(https://www.cloudflare.com/terms/)中有多处提及禁止将其基础设施用于”绕过访问控制””未授权访问””违反当地法律或服务提供方政策”等行为。而在其社区、工单回复及实际封号案例中，也多次明确指出：

• 不允许通过 Cloudflare Tunnel 建立代理、VPN 或流量转发服务；
• 若发现有大量非典型流量或 Proxy 行为，可能会自动触发流控、封禁子域名甚至停用账号；
• 特别强调了对”与公众网络无关”的流量（如内网代理、翻墙用途）的高敏感度。

这就意味着，尽管技术上可行，实际上并不合规：能用，不等于该用。在目前环境下，Cloudflare Tunnel 确实是少数能稳定用于”非直连”科学链路的通道之一，但从服务协议和实际风险来看，它更适合作为开发、演示、远程管理等”合理用途”的隧道服务。

如果你执意将其用于科学服务：

• 建议仅限个人低频使用；
• 尽可能设置访问控制、隐藏路径，并规避大流量行为；
• 最重要的是，不要对外公开、传播使用方式或服务地址，避免波及整个 Tunnel 生态。

毕竟，Cloudflare 并不是来帮你”科学”的，它的目标是为 Web 应用提供安全、合规的加速和防护服务。

5 基于sing-box的科学节点搭建

5.1 sing-box介绍

其实，除了前面讲的一堆理论内容，我原本并不打算详细讲具体工具的使用。一方面是这类内容总归有些敏感，另一方面，工具和协议的选择本身也并没有绝对的”最优解”——更重要的是理解背后的原理和结构。不过，为了让这篇文章的结构更加完整，也为了帮助一些刚入门的朋友能更好地把前面讲的内容”落地”，我还是简单讲一下工具的配置示范。

目前比较主流的选择包括 Xray、Hysteria、NaïveProxy、tuic 等工具，每个都有各自的特色和使用场景。但考虑到稳定性、灵活性和更新活跃度，我最终还是选用了sing-box作为示例。

与传统的”一个协议跑到底”的思路不同，sing-box 更像是一个高度模块化的代理框架。它的定位非常清晰：融合多个代理协议，提供极强的可配置性，并为高级用户提供构建复杂科学场景的能力。

在协议支持上，sing-box 是目前少数同时具备广泛传入与传出协议支持的代理工具。它可以作为客户端运行，也可以作为远端服务端，甚至能用于构建分层的多级转发结构（比如”DNS 分流 + TLS 转发 + 多出口出站”）。常见的代理协议如 VLESS、Trojan、Shadowsocks、Hysteria2、Tuic、SOCKS、WireGuard 等都被完整支持，而出站协议甚至还包括 VMess（兼容模式）、HTTP、DNS 分流等，几乎囊括了所有主流需求。

除了协议本身，sing-box 对传输层的支持也很全面。它原生支持 TLS、Reality、WebSocket、gRPC、QUIC、XTLS 等传输机制，用户可以根据实际需求灵活组合，实现既隐蔽又稳定的流量伪装。

配置方面，sing-box 的优势在于”清晰而强大”。虽然没有像一些 GUI 客户端那样”一键配置”，但 JSON 配置文件结构明确，官方文档完善，支持注释，逻辑也高度自洽。它不像 Xray 那样将很多行为隐藏在”不说你就猜不到”的默认逻辑里，而是鼓励你显式地定义每一个行为细节。一旦理解了核心架构，就能写出完全可控、行为透明的配置文件。不仅如此，它还自带命令行调试工具，可以用于检查路由匹配、测试连接、分析链路，这对排障非常关键。

值得一提的是，在新协议的支持方面，sing-box 也明显领先于其它工具。例如，它是最早支持 Reality 的代理项目之一，这是一种不依赖证书、模拟真实 TLS 流量的新机制，极大提升了隐蔽性；又比如 Hysteria 2 和 Tuic 2，这些基于 QUIC 的抗干扰协议，也都在 sing-box 中得到了第一时间的支持。此外，它还内置混淆（obfuscation）插件系统，允许用户自定义混淆规则，进一步提升抗干扰能力。

总的来说，如果你希望自己可以完全掌控节点行为，灵活定义每一个出入站流量、精细控制伪装方式与协议细节，那么 sing-box 是目前最值得深入学习和使用的核心工具之一：它并不是为了”简化科学上网”而生，而是为了在复杂环境中依旧保持自由而生的。

5.2 安装sing-box

5.2.1 APT方式安装

mkdir -p /etc/apt/keyrings

curl -fsSL https://sing-box.app/gpg.key -o /etc/apt/keyrings/sagernet.asc

chmod a+r /etc/apt/keyrings/sagernet.asc

   echo '
Types: deb
URIs: https://deb.sagernet.org/
Suites: *
Components: *
Enabled: yes
Signed-By: /etc/apt/keyrings/sagernet.asc
' | tee /etc/apt/sources.list.d/sagernet.sources

apt-get update

apt-get install sing-box

检查版本及功能：

sing-box version

注：使用默认apt方式安装的只是最新release的正式版。

5.2.2 直接下载官方构建版本

除了apt方式，也可以直接使用官方构建的版本，还是以v1.11.10版本为例：

wget https://github.com/SagerNet/sing-box/releases/download/v1.11.10/sing-box-1.11.10-linux-amd64.tar.gz

tar -xzf sing-box-1.11.10-linux-amd64.tar.gz

cp sing-box-1.11.10-linux-amd64/sing-box /usr/local/bin

chmod +x /usr/local/bin/sing-box

5.2.3 docker方式安装

5.2.3.1 docker run方式：

docker run -d \
  -v /etc/sing-box:/etc/sing-box/ \
  --name=sing-box \
  --restart=always \
  ghcr.io/sagernet/sing-box \
  -D /var/lib/sing-box \
  -C /etc/sing-box/ run

5.2.3.2 docker compose方式的配置文件

version: "3.8"
services:
  sing-box:
    image: ghcr.io/sagernet/sing-box
    container_name: sing-box
    restart: always
    volumes:
      - /etc/sing-box:/etc/sing-box/
    command: -D /var/lib/sing-box -C /etc/sing-box/ run

5.3 创建配置目录与配置文件

5.3.1 碎碎念

sing-box有一点比较坑，不同版本之间的配置文件可能存在较大差异，因为它的开发节奏非常快，更新频繁，很多功能在不断重构与重命名。例如，一些旧版本中的字段在新版本中被合并或拆分，某些模块的行为逻辑也会随着版本迭代发生变化。这就导致网上很多教程、甚至是官方文档中，不同时间撰写的示例配置彼此不兼容，初学者很容易踩坑。

特别是当你参考他人配置时，如果两边的版本号差距较大(其实未必较大时才有问题，那么就相差一个小版本一样难说～)，很可能出现”配置看起来没错，但根本跑不起来”的情况。因此，使用 sing-box 时一定要注意确保教程示例、自己的程序版本、官方文档三者的一致性，否则调试过程可能会变得非常痛苦。

友情提醒：如果你追求稳定，建议在验证过可用配置后锁定版本使用；如果你想用上最新特性，比如 Reality、Tuic2 等高级功能，那就要做好跟着版本日志不断更新配置的心理准备。

5.3.2 Server端配置示范(v1.11.10)

新建目录并创建config.json配置文件：

mkdir -p /etc/sing-box
vim /etc/sing-box/config.json

采用”vless+tls+websocket”方式，填入如下配置(server端配置)：

{
  "log": {
    "level": "info" // 设置日志等级，可选: trace/debug/info/warn/error。这里设为 info，表示输出一般运行信息。
  },
  "inbounds": [
    {
      "type": "vless", // 入站协议类型为 VLESS
      "listen": "0.0.0.0", // 监听所有网卡的 IP 地址
      "listen_port": 8443, // 监听端口为 8443，客户端需连接此端口
      "users": [
        {
          "uuid": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" // 用户认证使用的 UUID，客户端配置中需保持一致
        }
      ],
      "tls": {
        "enabled": true, // 启用 TLS 加密
        "server_name": "xxx.exapmle.com", // SNI（Server Name Indication），应与证书中的域名一致
        "certificate_path": "/etc/certs/xxx.exapmle.com/fullchain.pem", // TLS 证书路径
        "key_path": "/etc/certs/xxx.exapmle.com/key.pem" // TLS 私钥路径
      },
      "transport": {
        "type": "ws", // 使用 WebSocket 作为传输层
        "path": "/websocket" // WebSocket 的访问路径，客户端需匹配
      }
    }
  ],
  "outbounds": [
    {
      "type": "direct" // 出站类型为直接连接（不代理），表示这是一个终端节点（非转发代理）
    }
  ]
}

上面配置中的uuid可以用在线工具生成，也可以使用我这个：uuid在线生成工具。

运行sing-box server端：

sing-box run -c /etc/sing-box/config.json

注1：本例中因为这是部署在海外VPS节点，所以”outbounds”采用direct方式直接出站即可；如果你打算让这个服务端将接收到的流量继续代理出去，那”outbounds”就不是 direct，而应该是指向其他代理节点(比如一个 shadowsocks、vless 或 trojan 的出站配置)。

注2：除了vless，还可以用trojan，这个看大家喜好，在Cloudflare Tunnel加持下，使用vless还是trojan其实都没啥区别(TLS都由Cloudflare来完成)，vless只是稍微轻量了一点点。

5.3.3 Client端配置示范(v1.11.10)

新建目录并创建config.json配置文件：

mkdir -p /etc/sing-box
vim /etc/sing-box/config.json

采用”vless+tls+websocket”方式，填入如下配置(client端配置)：

{
  "log": {
    "level": "info" // 设置日志等级，这里为 info，表示输出常规信息
  },
  "inbounds": [
    {
      "type": "http", // 入站类型为 HTTP 代理
      "tag": "http-in", // 标记名称，可用于路由等功能中引用
      "listen": "0.0.0.0", // 监听所有网卡地址
      "listen_port": 8080 // HTTP 代理监听端口为 8080
    },
    {
      "type": "socks", // 入站类型为 SOCKS5 代理
      "tag": "socks-in", // 标记名称
      "listen": "0.0.0.0", // 监听所有网卡地址
      "listen_port": 1080 // SOCKS5 代理监听端口为 1080
    }
  ],
  "outbounds": [
    {
      "type": "vless", // 出站协议类型为 VLESS，用于连接服务端
      "tag": "vless-out", // 出站标记，可用于路由匹配
      "server": "xxx.exapmle.com", // VLESS 服务端域名或 IP 地址
      "server_port": 443, // 服务端监听的端口，配合 TLS 使用
      "uuid": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", // 身份验证用 UUID，需与服务端配置一致
      "tls": {
        "enabled": true, // 启用 TLS 加密
        "server_name": "xxx.exapmle.com" // TLS 握手时使用的 SNI，应与服务端证书一致
      },
      "transport": {
        "type": "ws", // 使用 WebSocket 传输方式
        "path": "/websocket" // WebSocket 的路径，应与服务端配置一致
      }
    }
  ],
  "route": {
    "auto_detect_interface": true, // 自动检测默认网络接口（比如出口网卡）
    "final": "vless-out" // 所有未被其他规则匹配的流量最终走 "vless-out" 这个出站
  }
}

这份配置适合用于将本地的 HTTP/SOCKS 请求统一转发到远程 VLESS 服务端，适合作为家庭内网中浏览器或局部应用的科学代理入口。

运行sing-box client端：

sing-box run -c /etc/sing-box/config.json

注：Client端UUID要和Server端UUID一致。

5.4 配置开机自动启动

创建service文件：

vim /etc/systemd/system/sing-box.service

粘贴并保存以下内容：

[Unit]
Description=Sing-box Service
After=network.target

[Service]
ExecStart=/usr/bin/sing-box run -c /etc/sing-box/config.json
Restart=on-failure
RestartSec=5s
LimitNOFILE=1048576

[Install]
WantedBy=multi-user.target

启用并启动服务：

systemctl daemon-reexec
systemctl daemon-reload
systemctl enable --now sing-box

检查服务状态：

systemctl status sing-box

6 总结

其实，无论你采用的是”直连”模式还是”非直连”模式，在 sing-box 的 server/client 配置层面几乎不需要做任何区别化的调整。决定访问方式的核心，往往只在于配置文件中 xxx.example.com 这个域名的解析指向。

以一个托管在 Cloudflare 上的域名为例：

• 如果你关闭了 Cloudflare 的代理功能（即关闭了那个”小橙云朵”图标），让域名通过 A 记录直接解析到 sing-box 部署节点的公网 IP，同时该节点开放并监听相应的端口，那么客户端访问该域名时，实际上就是直接连接节点，属于典型的”直连”模式。
• 相反，如果你开启了 Cloudflare 的代理功能（打开”小橙云朵”），那么域名就不会暴露真实的 IP，而是通过 Cloudflare 的边缘网络进行回源。这时有两种形式：
  1. 传统代理方式：Cloudflare 通过公网回源到你的节点（公网 IP + 监听端口）；
  2. Tunnel 模式：你在节点端运行了 Cloudflare Tunnel 客户端，Cloudflare 通过 tunnel 的专用隧道进行回源。

这两种方式都属于典型的”非直连”模式，因为访问链路中总有一段是”非真实 IP”的中转层。因此，可以说：“直连”还是”非直连”的区别，关键并不在 sing-box 本身的配置内容，而在于你如何通过 DNS 和 Cloudflare 控制访问流量的入口路径。

注：如果采用基于cloudflare tunnel的”非直连”模式，会有几个配置注意点，参见我另一篇文章：dnscrypt-proxy(v2.1.8) 多场景配置指南：从上游部署到下游集成。