Sing-box 搭建您的专属“科学上网”节点实用指南

简介

Sing-box 简介：强大的通用代理平台

Sing-box 是一款新兴且功能强大的通用代理平台，被广泛认为是 V2Ray 和 Xray 等成熟工具的有力替代品。它凭借其卓越的性能、轻量化的设计、对多种代理协议的广泛支持、高度模块化的架构以及积极的社区开发，迅速获得了用户的青睐。Sing-box 基于 Go 语言开发，并以开源形式发布，这不仅保证了其透明度和安全性，也促进了社区的共同发展和完善。

本教程目标

本教程旨在提供一个从零开始的详尽指南，帮助具备一定技术背景的用户在自己的服务器上成功安装和配置 sing-box，并部署多种当前流行且高效的代理协议。通过本教程，用户将能够：

选择合适的服务器并完成 sing-box 的安装。
理解 sing-box 的核心概念和配置文件结构。
配置服务器防火墙，确保代理服务的正常运行。
详细配置 VLESS (配合 Reality)、Trojan (配合 TLS)、Shadowsocks (2022新加密)、Hysteria2 和 TUIC 等主流代理协议。
了解客户端的基本配置方法和主流客户端软件。
初步接触如使用 CDN 隐藏服务器 IP、配置基本路由和故障转移等高级技巧。

尽管本教程力求详尽，但 sing-box 的功能远不止于此。鼓励用户在掌握基础后，进一步查阅其官方文档，探索更多高级定制功能，以满足个性化需求。

第一章：理解与安装 Sing-box

1.1. Sing-box 核心概念：构建代理节点的基石

理解 sing-box 的核心组件及其交互方式，是成功配置和高效使用该平台的基础。其模块化设计允许用户灵活组合不同的功能模块，以适应多样化的网络环境和需求。

入站连接 (Inbounds): 入站连接负责处理从客户端设备（例如您的电脑或手机）传入 sing-box 服务器的连接请求。Sing-box 支持多种入站协议类型，常见的包括 Shadowsocks、Trojan、VLESS、VMess、Hysteria2、TUIC、Naive、ShadowTLS，以及用于创建虚拟网卡的 Tun 和用于透明代理的 Redirect 等。用户可以根据客户端的支持情况和安全需求选择合适的入站协议。
出站连接 (Outbounds): 出站连接定义了 sing-box 服务器如何处理经过其的数据流，即如何将数据转发到目标互联网地址或其他代理服务器。常见的出站类型有 Direct（直接连接）、Block（阻止连接）、Shadowsocks、Trojan、VLESS、WireGuard、Hysteria2、TUIC，以及专门用于 DNS 查询的 DNS、用于节点选择的 Selector 和用于故障转移的 URLTest 等。这种设计使得 sing-box 不仅能作为代理服务器，还能作为客户端连接其他代理，或实现复杂的代理链。
路由 (Route): 路由模块是 sing-box 实现精细化流量控制的核心。用户可以通过定义一系列路由规则，根据流量的目标地址（如 GeoIP 数据库判断的地理位置、Geosite 预设的网站域名集合）、域名、协议类型等多种条件，将特定的流量导向不同的出站连接。例如，可以配置国内网站直连，国外网站通过代理访问，从而优化访问速度和资源利用。
DNS 配置: DNS（域名系统）在网络通信中扮演着将域名转换为 IP 地址的关键角色。Sing-box 内建了强大的 DNS 处理能力，允许用户配置自定义 DNS 服务器、设定 DNS 路由规则，并支持如 FakeIP（虚拟 IP）等高级功能，以防止 DNS 泄露，确保域名解析的准确性和安全性。
配置文件 (config.json): Sing-box 的所有配置均通过一个 JSON 格式的文件进行管理，通常命名为 config.json 。该文件包含了日志、DNS、入站、出站、路由等所有模块的配置信息。其顶层结构通常如下所示：
```
{
  "log": {},
  "dns": {},
  "inbounds":,
  "outbounds":,
  "route": {},
  "experimental": {}
}
```
熟悉 JSON 语法并理解各配置项的含义对于手动配置 sing-box至关重要。

sing-box 的架构设计体现了高度的模块化，官方文档在其配置结构中明确区分了入站、出站和路由等组件。这种设计带来了显著的灵活性，例如支持同时作为客户端和服务器运行，以及实现多协议负载均衡。这意味着用户可以根据具体需求自由组合这些模块，构建从简单的个人代理到复杂的多跳转发网关等各种应用场景，这相较于一些功能固化的工具是一个显著的优势。

1.2. 选择您的服务器 (VPS)：地理位置与操作系统考量

选择一台合适的虚拟专用服务器（VPS）是搭建稳定高效代理服务的前提。以下是一些关键考量因素：

地理位置: 服务器的地理位置直接影响到您的访问速度和能否顺畅访问特定区域的内容。应选择距离用户较近且能提供良好国际网络连接的地区。
服务商信誉: 选择知名且信誉良好的 VPS 服务商，以确保服务的稳定性、可靠的技术支持和合理的资源分配。
资源需求: 根据预期的负载情况，选择合适的 CPU、内存（RAM）和带宽。对于个人使用，通常入门级配置即可满足需求，但如果用户较多或流量较大，则需相应提高配置。
操作系统: 强烈推荐选用 Linux 发行版，特别是 Ubuntu 或 Debian。这两个发行版拥有庞大的用户社区、丰富的文档资源，并且 sing-box 官方提供了便捷的安装脚本和软件包支持。

绝大多数关于 sing-box 及类似代理工具的安装指南和社区讨论都集中在 Linux 平台。这并非偶然，Linux 服务器以其经济高效、命令行环境的强大管理能力以及 systemd 等标准化服务管理工具 1成为自建代理服务的首选。Sing-box 本身也对 Linux 提供了深度支持，包括一些依赖特定操作系统内核的功能（如 TUN 模式）。因此，对于追求稳定、文档完善且易于维护的服务器端部署而言，选择 Ubuntu 或 Debian Linux 将是最直接且高效的路径。

1.3. 在您的服务器上安装 Sing-box (以 Ubuntu/Debian 为例)

Sing-box 提供了多种安装方式，对于 Ubuntu/Debian 系统，推荐使用官方提供的安装脚本，操作简便快捷。

使用官方通用安装脚本:

通过以下命令下载并执行安装脚本，该脚本会自动检测系统并安装最新稳定版的 sing-box：
```
curl -fsSL https://sing-box.app/install.sh | sudo bash
```
如果偏好专门为 Debian/Ubuntu 优化的脚本，可以使用：
```
curl -fsSL https://sing-box.app/deb-install.sh | sudo bash
```
安装特定版本或 Beta 测试版:

如果需要安装 Beta 版本以体验最新功能，或指定安装某一特定版本，可以在执行脚本时附加参数：
- 安装最新 Beta 版：
```
curl -fsSL https://sing-box.app/install.sh | sudo bash -s -- --beta
```
- 安装特定版本 (例如 1.8.0)：
```
curl -fsSL https://sing-box.app/install.sh | sudo bash -s -- --version 1.8.0
```

通过 APT 软件源安装 (适用于 Debian/Ubuntu):

对于希望通过系统包管理器管理 sing-box 的用户，可以添加 SagerNet 的官方 APT 软件源：

sudo mkdir -p /etc/apt/keyrings && \
sudo curl -fsSL https://sing-box.app/gpg.key -o /etc/apt/keyrings/sagernet.asc && \
sudo chmod a+r /etc/apt/keyrings/sagernet.asc && \
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/sagernet.asc] https://deb.sagernet.org/ * *" | \
sudo tee /etc/apt/sources.list.d/sagernet.list > /dev/null && \
sudo apt-get update && \
sudo apt-get install sing-box

这种方式便于后续的更新和维护。

其他操作系统安装简介:

尽管本教程主要关注 Linux 服务器，但 sing-box 的命令行版本也支持其他操作系统。例如，macOS 用户可以通过 Homebrew (brew install sing-box) 安装，Windows 用户可以使用 Scoop (scoop install sing-box) 或 Chocolatey (choco install sing-box) 进行安装。这些主要适用于在本地计算机上使用 sing-box 命令行客户端的场景。

1.4. Sing-box 核心命令行工具 (CLI)

掌握 sing-box 的命令行工具对于服务器管理、配置调试和自动化操作至关重要。以下是一些最常用的命令：

sing-box version: 显示已安装的 sing-box 版本信息，包括构建标签 (build tags) 。构建标签指明了编译时包含了哪些特性，例如 with_reality_server 表示支持 Reality 协议，with_quic 表示支持 QUIC 协议。
sing-box run -c /etc/sing-box/config.json: 使用指定的配置文件启动 sing-box 服务。默认情况下，sing-box 会查找 /etc/sing-box/config.json。
sing-box check -c /etc/sing-box/config.json: 校验配置文件的语法和基本逻辑是否正确，这是在启动或重启服务前非常重要的一步。
sing-box format -w -c /etc/sing-box/config.json: 格式化（美化）JSON 配置文件，使其更易读。-w 参数表示直接写入修改到原文件。
sing-box generate uuid: 生成一个标准的 UUID (通用唯一识别码)，常用于 VLESS、VMess 等协议的用户ID配置。
sing-box generate reality-keypair: 生成一对公私钥，专用于配置 VLESS Reality 协议。
通过 systemd 管理服务 (若已安装为系统服务):
- sudo systemctl start sing-box: 启动服务。
- sudo systemctl stop sing-box: 停止服务。
- sudo systemctl restart sing-box: 重启服务。
- sudo systemctl enable sing-box: 设置服务开机自启。
- sudo systemctl status sing-box: 查看服务运行状态。
- sudo journalctl -u sing-box -f --output cat: 实时查看服务日志（ -f 表示 follow，--output cat 以简化格式输出）。

sing-box 提供的一系列命令行工具，覆盖了从运行、配置管理到密钥生成的各个核心环节。这些工具不仅是手动管理 sing-box 实例的基础，更是实现自动化部署、配置更新等高级操作的基石。例如，generate uuid 和 generate reality-keypair 等命令简化了需要特定加密材料的协议的配置过程。同时，通过 systemctl 与 Linux 标准服务管理体系的集成，确保了 sing-box 服务的稳定可靠运行。因此，即使未来出现更多图形化管理界面，熟练运用这些命令行工具对于任何希望深度掌控和高效运维 sing-box 服务器的管理员来说，都是不可或缺的技能。

1.5. `config.json` 文件结构解析 (再探)

再次强调 config.json 的核心地位及其主要构成部分，有助于用户在后续章节中更好地理解和修改配置。

log: 配置日志记录的级别（如 info, warn, error, debug, trace）、输出位置（默认标准输出，可指定文件路径）以及是否添加时间戳等。
dns: 管理 DNS 解析行为，包括设置上游 DNS 服务器、DNS 策略（如 IPv4_only）、DNS 规则（如根据域名分流到不同 DNS 服务器）、FakeIP 等。
ntp: 网络时间协议 (NTP) 配置，用于同步服务器时间，确保时间准确性，这对于某些依赖时间戳的加密协议和证书验证非常重要。
inbounds: 定义一个或多个入站连接处理器。每个入站配置指定了监听的 IP 地址、端口、协议类型（如 VLESS, Trojan）以及该协议所需的用户认证、TLS 等参数。
outbounds: 定义一个或多个出站连接处理器。每个出站配置指定了连接的目标服务器、端口、协议类型（如 direct 直连, block 阻止, 或具体的代理协议）以及相应的认证和传输参数。
route: 包含路由规则列表。这些规则决定了符合特定条件的入站流量应该被转发到哪个出站连接。规则可以基于域名、IP、地理位置、端口、进程名等多种条件。
experimental: 用于配置一些实验性功能，例如 Clash API 兼容接口，允许通过 Clash 兼容的控制面板管理 sing-box 。

对这些主要部分的理解，将为后续针对不同协议的具体配置打下坚实基础。

第二章：准备您的服务器环境

在正式配置 sing-box 代理协议之前，确保服务器环境的安全性与网络通畅性至关重要。

2.1. 基础服务器安全加固 (简述)

一台暴露在公网的服务器需要基本的安全防护措施：

系统更新:

始终保持操作系统及其软件包为最新版本，以修复已知的安全漏洞。
```
sudo apt update && sudo apt upgrade -y
```
SSH 安全:
- 使用密钥认证: 强烈建议禁用密码登录，转而使用 SSH 密钥对进行认证，这能极大提高登录安全性。
- 禁止 root 登录: 修改 SSHD 配置 (/etc/ssh/sshd_config)，设置 PermitRootLogin no，并使用普通用户登录后再通过 sudo 执行特权命令。
- (可选) 修改 SSH 默认端口: 将 SSH 服务从默认的 22 端口迁移到其他非标准端口，可以在一定程度上减少自动化的扫描和爆破尝试，但这更多的是一种“安全靠隐蔽”的次要措施。

本教程不提供详尽的服务器安全指南，以上仅为最基础的建议。用户应根据自身情况参考更专业的安全文档进行加固。

2.2. 防火墙配置：为代理协议开放端口

防火墙是服务器的第一道网络防线，它控制着哪些端口允许外部访问。您必须为计划使用的代理协议开放相应的服务器端口。

在 Ubuntu/Debian 上使用 UFW (Uncomplicated Firewall):

UFW 是一个用户友好的防火墙管理工具。
1. 安装 UFW (如果尚未安装):
```
sudo apt install ufw
```
2. 设置默认策略:
  
  拒绝所有传入连接，允许所有传出连接。
```
sudo ufw default deny incoming
sudo ufw default allow outgoing
```
3. 允许 SSH 连接 (关键步骤):
  
  在启用 UFW 之前，务必先允许 SSH 连接，否则您可能会失去对服务器的访问权限。
```
sudo ufw allow ssh
```
  或者，如果您修改了 SSH 端口：
```
sudo ufw allow <您的_SSH_端口>/tcp
```
4. 为代理协议开放端口:
  
  根据您选择的协议和配置的端口，使用以下命令开放 TCP 和/或 UDP 端口。例如，如果您计划在 8443 端口上运行一个 TCP 协议，在 9000-9005 端口范围运行一个 UDP 协议：
```
sudo ufw allow 8443/tcp
sudo ufw allow 9000:9005/udp
```
5. 启用 UFW:
```
sudo ufw enable
```
  系统会提示操作可能中断现有 SSH 连接，确认即可。
6. 查看状态:
```
sudo ufw status verbose
```

在 CentOS/RHEL/Fedora (及部分 Debian/Ubuntu) 上使用 firewalld:

firewalld 是另一款常用的动态防火墙管理工具。

查看 firewalld 状态:
```
sudo firewall-cmd --state
```

永久开放端口:

sudo firewall-cmd --permanent --add-port=<端口号>/tcp
sudo firewall-cmd --permanent --add-port=<端口号>/udp
sudo firewall-cmd --permanent --add-port=<起始端口>-<结束端口>/tcp

永久开放服务 (例如 HTTPS，如果协议伪装在 443 端口):
```
sudo firewall-cmd --permanent --add-service=https
```
重新加载 firewalld 配置使其生效:
```
sudo firewall-cmd --reload
```
查看已开放的端口:
```
sudo firewall-cmd --list-ports
```

表 2.2.1: 常见代理协议及其默认/推荐端口

协议	默认/常用端口	TCP/UDP	备注
VLESS (Reality)	443, 80, 其他自定义端口	TCP	常使用 443 端口伪装成 HTTPS。Reality 可灵活使用多种端口。
Trojan (TLS)	443	TCP	通常使用 443 端口进行 TLS 加密通信。
Shadowsocks	用户自定义 (如 8388, 443)	TCP/UDP	无标准端口；443 端口可用于流量混淆。
Hysteria2	用户自定义	UDP	基于 QUIC，常使用高位端口或 443/udp。
TUIC	用户自定义	UDP	基于 QUIC，常使用高位端口或 443/udp。
VMess	用户自定义	TCP/UDP	无标准端口。
ShadowTLS	443 (外层)	TCP	包装其他协议，外层连接通常在 443 端口。
NaiveProxy	443, 80	TCP	模仿标准 Web 流量。

无论是 UFW 还是 firewalld，其默认策略通常是拒绝所有未经明确允许的入站连接。这是一种基础且重要的安全实践，旨在最小化服务器的潜在攻击面。因此，用户必须显式地为 SSH（远程管理）和计划运行的代理协议开放端口。忽略或错误配置防火墙，不仅可能导致代理服务无法访问，还可能使服务器暴露于不必要的安全风险之下。因此，防火墙的正确配置是保障代理节点正常运作和安全性的前提条件。

第三章：在 Sing-box 中配置热门协议

本章节将详细介绍如何在 sing-box 中配置当前流行且在“科学上网”场景下表现优异的几种代理协议。每个协议的配置都将包含服务器端（入站）和客户端（出站）的 JSON 代码片段，并对关键字段进行解释。

通用说明：

每个协议小节都会简要介绍其特性、基于的传输方式（TCP/UDP）、加密和混淆技术，以及其在规避审查方面的有效性。
所有配置示例均为 sing-box 的 JSON 格式，并附带注释说明。
会提及配置该协议可能需要的前提条件，如域名、SSL 证书、生成的密钥对等。

3.1. VLESS (配合 Reality 和/或 XTLS-Vision)

协议概述: VLESS 以其高性能和灵活性著称。Reality 是一种先进的流量伪装技术，它使得代理服务器在未授权的探测者看来完全像一个真实的、普通的网站（例如 www.microsoft.com），从而极大地增强了抗审查能力。XTLS-Vision 是一种流控模式，旨在进一步优化性能。

服务器 (入站) 配置 (VLESS + Reality):

{
  "inbounds":,
      "tls": {
        "enabled": true,
        "server_name": "your.actual.domain.com", // 你的真实域名，用于申请证书 (如果使用 ACME)
        "reality": {
          "enabled": true,
          "handshake": {
            "server": "www.microsoft.com", // 伪装的目标网站域名
            "server_port": 443
          },
          "private_key": "YOUR_REALITY_PRIVATE_KEY", // 使用 'sing-box generate reality-keypair' 生成
          "short_id":, // 1到2个字节的十六进制字符串，例如 "01" 或 "abcd"
          "max_time_difference": "1m" // 允许客户端与服务器的最大时间差
        }
        // 如果不使用 Reality 自签名证书，而是为 your.actual.domain.com 申请真实证书，
        // 则需要配置 ACME 或 certificate_path/key_path
        // "acme": {
        //   "domain": "your.actual.domain.com",
        //   "email": "your-email@example.com"
        // }
      }
    }
  ]
}

关键解释:
- uuid: 用户的唯一标识符。
- tls.server_name: 对于 Reality 而言，此处的 server_name 是您希望 Reality “伪装”成的目标网站的域名，客户端连接时会使用这个 SNI。
- reality.handshake.server: 实际发起 TLS 握手的目标服务器，通常是知名的大型网站，以增加伪装的真实性。
- reality.private_key: 通过 sing-box generate reality-keypair 命令生成的私钥。公钥需要配置在客户端。
- reality.short_id: 一个或多个短ID（1-2字节的十六进制字符串），客户端连接时需要匹配其中一个。
- flow: "xtls-rprx-vision": VLESS 的一种流处理模式，可提升性能。

客户端 (出站) 配置 (VLESS + Reality):
```
{
  "outbounds":
}
```
- 关键解释:
  - tls.server_name: 客户端在发起 TLS 握手时使用的 SNI，必须与服务器端 reality.handshake.server 字段中配置的域名完全一致。
  - tls.reality.public_key: 服务器端通过 sing-box generate reality-keypair 生成的公钥。
  - tls.utls.fingerprint: 模拟特定浏览器的 TLS 指纹，例如 “chrome”, “firefox”, “safari” 等，这有助于使流量看起来更像普通浏览器发出的流量，从而进一步抵抗指纹识别。

Reality 技术的出现，是针对日益复杂的网络审查中主动探测和基于 SNI 封锁的有效回应。传统的代理协议，即使流量加密，其 TLS 握手特征或服务器行为也可能被主动探测识别。同时，审查系统也可能直接封锁指向可疑服务器 IP 的特定 SNI 请求。Reality 通过“借用”一个高信誉、大流量的知名网站（如 www.microsoft.com）的 TLS 握手信息作为“外壳”，使得 sing-box 服务器在初始连接阶段的行为与该知名网站无法区分，从而有效规避主动探测。在这次“伪装”握手之后，真实的 VLESS 代理流量才通过这对由 private_key 和 public_key 保护的加密通道进行传输。这种机制使得 VLESS + Reality 组合在当前环境下拥有极高的隐蔽性和抗封锁能力，是其广受欢迎的主要原因。

3.2. Trojan (配合 TLS，可选 WebSocket 传输)

协议概述: Trojan 协议通过模仿 HTTPS 流量的特征，使其在网络传输中难以被识别和区分。它通常需要配合一个真实的域名和有效的 SSL/TLS 证书使用。WebSocket (WS) 作为一种可选的传输层协议，可以将 Trojan 流量进一步封装在标准的 HTTP/HTTPS 连接中，这不仅增强了伪装性，还使得流量可以通过 CDN (内容分发网络) 进行中转，隐藏真实服务器 IP 。

服务器 (入站) 配置 (Trojan + TLS):

{
  "inbounds":,
      "tls": {
        "enabled": true,
        "server_name": "your.domain.com", // 你的域名
        // 使用 ACME 自动申请和续签证书 (推荐)
        "acme": {
          "domain": "your.domain.com",
          "email": "your-email@example.com"
        }
        // 或者手动指定证书路径
        // "certificate_path": "/path/to/your/fullchain.pem",
        // "key_path": "/path/to/your/private.key"
      },
      "multiplex": { // 启用多路复用以提高性能
        "enabled": true
      }
      // 如果需要 WebSocket 传输 (例如配合 CDN)
      // "transport": {
      //   "type": "ws",
      //   "path": "/your-secret-websocket-path" // 自定义 WebSocket 路径
      // }
    }
  ]
}

关键解释:
- users.password: Trojan 协议的认证密码。
- tls.server_name: 必须是您拥有的、并且 DNS 解析指向您服务器 IP 的域名。
- tls.acme: 推荐使用 ACME 自动管理 TLS 证书，sing-box 支持 Let’s Encrypt 等机构。
- multiplex.enabled: 启用多路复用可以减少连接数，提高并发处理能力。
- transport (可选): 如果配置为 "ws"，则启用 WebSocket 传输。path 是 WebSocket 的访问路径，应设置为一个不易被猜到的字符串。

客户端 (出站) 配置 (Trojan + TLS):
```
{
  "outbounds":
}
```
29 (WebSocket 部分参考 39)
- 关键解释:
  - server: 连接的服务器地址，推荐使用域名。
  - tls.server_name: 客户端进行 TLS 握手时提供的 SNI，必须与服务器证书绑定的域名一致，否则会导致握手失败。
  - tls.utls.fingerprint: 模拟特定浏览器的 TLS 客户端行为，增强伪装性。
  - transport.headers.Host (使用 WS 时): 当通过 CDN 或反向代理连接时，通常需要设置正确的 Host 头，使其指向您的源服务器域名。

Trojan 协议的核心设计理念在于其高度的 HTTPS 流量模拟能力。配置中对 TLS 参数（如 server_name、certificate_path、key_path）的强调，正是为了实现这种逼真的伪装。一个与 server_name（即您的域名）匹配的有效 TLS 证书，是构成可信 HTTPS 通信的基础。如果使用自签名证书或 SNI 不匹配，很容易被中间的网络设备识别为异常流量。将 Trojan 服务部署在标准的 HTTPS 端口 443 上，能进一步增强其隐蔽性。因此，选择 Trojan 协议的用户，必须准备好获取一个域名，并为该域名配置有效的 TLS 证书（可以通过 sing-box 内置的 ACME 功能自动申请，或手动配置）。若缺乏这些要素，Trojan 协议主要的伪装特性将大打折扣，其抗审查能力也会显著下降。

3.3. Shadowsocks (重点关注 AEAD 2022 系列加密算法)

协议概述: Shadowsocks 是一种轻量级、广泛应用的代理协议。其 2022 系列的 AEAD (Authenticated Encryption with Associated Data) 加密算法，如 2022-blake3-aes-128-gcm，因其在安全性和抗探测性方面的提升而被官方推荐使用。
服务器 (入站) 配置:
```
{
  "inbounds":
}
```
- 关键解释:
  - method: 选择一个 2022 系列的 AEAD 加密算法。
  - password: Shadowsocks 的连接密码。
  - multiplex.enabled: 启用多路复用。对于 Shadowsocks 而言，这不仅能提升性能，还能改善 UDP 流量的传输和隐蔽性。
客户端 (出站) 配置:
```
{
  "outbounds":
}
```

sing-box 官方文档在介绍 Shadowsocks 时，强烈建议开启多路复用功能来传输 UDP 流量，并指出“否则很容易受到被动检测” 。究其原因，传统的 Shadowsocks 实现（尤其是较早的加密方式或未启用多路复用的 UDP 传输）存在一些可被深度包检测（DPI）识别的流量特征。多路复用技术（如 Shadowsocks 常用的 smux）允许在单个 TCP 连接上承载多个逻辑数据流，这不仅改变了流量模式，使其更难与使用连接池的常规网络流量区分开来，还为在 TCP 连接内隧道化 UDP 数据包提供了一种更为健壮和标准化的方式，这在许多受审查的网络环境中比直接转发原始 UDP 包更为可靠。因此，在 sing-box 中配置 Shadowsocks 时，用户应始终启用多路复用，特别是当需要可靠传输 UDP 流量（例如用于 QUIC 协议的应用、WebRTC 或在线游戏）时。忽视此建议将显著增加协议被探测和封锁的风险。

3.4. Hysteria2 (基于 QUIC，高性能)

协议概述: Hysteria2 专为在不稳定和高丢包网络环境下提供高速传输而设计。它基于定制的 QUIC 协议，并采用名为 “Brutal” 的拥塞控制算法，力求在恶劣网络条件下榨干带宽。其流量特征旨在伪装成标准的 HTTP/3 流量。

服务器 (入站) 配置:

{
  "inbounds":,
      "tls": {
        "enabled": true,
        "server_name": "your.domain.com", // 你的域名
        // 使用 ACME 自动申请证书
        "acme": {
          "domain": "your.domain.com",
          "email": "your-email@example.com"
        }
        // 或手动指定证书
        // "certificate_path": "/path/to/your/fullchain.pem",
        // "key_path": "/path/to/your/private.key"
      },
      "obfs": { // 可选的 QUIC 流量混淆
         "type": "salamander", // 目前仅支持 salamander
         "password": "YOUR_OBFS_PASSWORD"
      }
    }
  ]
}

关键解释:
- up_mbps, down_mbps: 定义服务器的上下行带宽限制。客户端也需要配置相应的值。
- users.password (或顶层 password): Hysteria2 的认证密码。注意 sing-box 不支持官方 Hysteria 客户端的 username:password 组合作为 userpass 的别名，需要直接填写组合后的密码。
- tls: Hysteria2 依赖 TLS 进行加密和认证，配置方式与 Trojan 类似，需要域名和证书。
- obfs (可选): Salamander 混淆器可以对 QUIC 流量进行额外处理，可能增加抗检测性，但也会带来性能开销。

客户端 (出站) 配置:
```
{
  "outbounds":
}
```

Hysteria2 的核心优势在于其基于 UDP (QUIC) 的特性以及独特的 “Brutal” 拥塞控制算法，这使其在网络质量较差、丢包率高的环境下仍能努力维持高吞吐量。然而，这也可能成为其潜在的弱点。正如 sing-box 文档所警示的，“基于 UDP 的代理……实际上比基于 TCP 的代理具有更明显的特征” 。尽管 QUIC 对大部分头部信息进行了加密，但在某些严格审查的网络中，大量非标准端口的 UDP 通信本身就可能引起注意。此外，“Brutal”拥塞控制算法为了追求带宽最大化，其产生的流量模式可能与常规 Web 流量所使用的标准 TCP 拥塞控制算法（如 Cubic 或 BBR）有所不同，长期来看存在被指纹识别的风险。因此，用户在选择 Hysteria2 时，应权衡其在恶劣网络下的性能优势与这种潜在的可检测性。

3.5. TUIC (基于 QUIC，低延迟)

协议概述: TUIC 是另一款基于 QUIC 的代理协议，其设计重点在于最小化连接握手延迟，并支持 0-RTT 连接建立。它也提供了高效的 UDP 代理能力。

服务器 (入站) 配置:

{
  "inbounds":,
      "congestion_control": "bbr", // 拥塞控制算法，可选 "cubic", "new_reno", "bbr"
      "auth_timeout": "3s", // 认证超时时间
      "heartbeat_interval": "10s", // 心跳间隔 (sing-box v1.9+ 使用此字段名)
      "tls": {
        "enabled": true,
        "server_name": "your.domain.com",
        "acme": {
          "domain": "your.domain.com",
          "email": "your-email@example.com"
        }
        // 或手动指定证书
        // "certificate_path": "/path/to/your/fullchain.pem",
        // "key_path": "/path/to/your/private.key"
      },
      // "zero_rtt_handshake": false // 服务端通常不建议开启 0-RTT，有安全风险
    }
  ]
}

(字段名 heartbeat_interval 对应新版 sing-box，旧版可能为 heartbeat)

关键解释:
- users: 包含 uuid 和 password 用于认证。
- congestion_control: 选择适合网络环境的 QUIC 拥塞控制算法。
- tls: 与 Hysteria2 类似，需要域名和证书。
- zero_rtt_handshake: 服务端通常应保持禁用（默认或显式设置为 false），以避免重放攻击的风险。

客户端 (出站) 配置:

{
  "outbounds":, // QUIC 通常使用 h3 作为 ALPN
        "utls": {
          "enabled": true,
          "fingerprint": "chrome"
        }
        // "insecure": true, // 如果服务器使用自签名证书且了解风险
      }
    }
  ]
}

TUIC 协议以其 0-RTT（零往返时间）握手能力作为提升连接速度、降低延迟的一大亮点。0-RTT 允许客户端在第一个数据包中就携带应用数据，这通过复用先前连接中协商好的会话参数来实现。然而，正如 sing-box 官方入站配置文档所强调的，服务端启用 zero_rtt_handshake 存在被重放攻击的风险，并引用了 Cloudflare 关于“克隆人攻击”的文章作为佐证。这种攻击的原理是，如果攻击者捕获了包含 0-RTT 数据的初始数据包，他们可以将这些数据包重放给服务器。由于服务器在处理 0-RTT 数据时无法轻易判断其新鲜度，这可能导致数据被重复处理或引发其他安全问题。尽管 QUIC 协议自身包含一些针对 0-RTT 的重放缓解措施，但并非万无一失。因此，对于注重安全性的应用场景，普遍建议谨慎对待 0-RTT，或避免将其用于非幂等请求。这意味着，尽管 TUIC 的 0-RTT 特性对延迟敏感型应用很有吸引力，用户必须清醒认识到相关的安全风险。为最大化安全性，服务端通常应禁用 0-RTT，即便这会牺牲部分握手延迟的极致优化。客户端仍可尝试发起 0-RTT 连接，但服务器端是否接受应由用户在充分理解并接受潜在风险后决定。

表 3.1: 特色协议对比概览

特性/协议	VLESS (+Reality)	Trojan (+TLS/WSS)	Shadowsocks (2022)	Hysteria2	TUIC
基础协议	TCP (VLESS 本身传输层无关)	TCP	TCP (UDP via Mux)	UDP (QUIC)	UDP (QUIC)
主要混淆方式	TLS (Reality 伪装真实网站)	TLS (模仿 HTTPS)	加密流, AEAD 加密	QUIC 加密 (伪装 HTTP/3)	QUIC 加密
隐蔽性 (vs GFW)	高 (Reality)	高 (如果配置得当)	中到高 (2022 + Mux)	中 (UDP 可能被针对)	中 (UDP 可能被针对)
性能表现	良好至优秀	良好	良好	优秀 (尤其在恶劣网络)	优秀 (低延迟)
配置复杂度	中 (Reality 增加步骤)	中 (需域名/证书)	低到中	中	中
核心优势	Reality 带来的高隐蔽性	强大的 HTTPS 模仿能力	简洁, 广泛支持	恶劣网络下的高吞吐	低握手延迟, 0-RTT 选项
主要劣势	Reality 配置可能较复杂	域名/证书管理	旧版/不当配置易被检测	UDP 封锁/限速, “明显特征” 30	UDP 封锁/限速, 0-RTT 风险

第四章：配置您的客户端设备

成功搭建 sing-box 服务器后，下一步是在您的设备上配置客户端以连接并使用该服务。

4.1. Sing-box 客户端通用配置原则

无论是使用 sing-box 命令行作为客户端，还是使用图形化客户端，其核心配置逻辑是相似的：客户端的 outbounds（出站）设置必须与服务器端的 inbounds（入站）设置相匹配。

关键匹配参数包括：

服务器地址 (server) 和端口 (server_port): 客户端必须正确指向服务器的 IP 地址或域名，以及服务器上相应协议监听的端口。
用户凭证 (UUID/password): 对于需要认证的协议（如 VLESS, Trojan, Shadowsocks, Hysteria2, TUIC），客户端配置的 UUID 或密码必须与服务器端为该用户设定的凭证完全一致。
加密方法 (method/security): 客户端选择的加密算法必须是服务器端支持并为该用户启用的。
传输设置 (transport): 如果服务器端使用了特定的传输方式（如 WebSocket 的路径 path，gRPC 的服务名 serviceName），客户端必须进行相应的配置。
TLS 设置 (tls):
- SNI (Server Name Indication): 对于使用 TLS 的协议，客户端配置的 server_name (SNI) 通常需要与服务器证书的域名或 Reality/Trojan 等协议期望的 SNI 一致。
- 证书验证: 客户端默认会验证服务器证书的有效性。如果服务器使用自签名证书，客户端需要配置信任该证书或（在了解风险的前提下）设置为不安全连接 (insecure: true)。
- Reality/uTLS: 如果服务器端配置了 Reality，客户端必须配置对应的 public_key 和 short_id。使用 utls 模拟浏览器指纹可以增强伪装性。
协议类型 (type): 客户端 outbounds 中的 type 字段必须与服务器端 inbounds 中配置的协议类型相对应。

4.2. 使用 Sing-box 命令行作为客户端 (适用于高级用户或连接其他服务器)

对于高级用户，或者当您希望将一台设备（如另一台服务器或本地 Linux/macOS 机器）作为连接到主 sing-box 服务器的客户端时，可以直接使用 sing-box 命令行程序。

以下是一个最小化的客户端 config.json 示例，它包含日志、DNS、一个连接到 VLESS+Reality 服务器的出站，以及一个本地 SOCKS5 入站，允许本机其他应用程序通过此 sing-box 客户端进行代理：

{
  "log": {
    "level": "info", // 日志级别，可根据需要调整为 "debug" 获取更详细信息
    "timestamp": true
  },
  "dns": {
    "servers":,
    "final": "dns-remote", // 默认所有 DNS 查询走 "dns-remote"
    "strategy": "ipv4_only" // DNS 解析策略，可按需选择
  },
  "inbounds":,
  "outbounds":,
  "route": {
    "rules":, "outbound": "direct" },
      // { "geosite": "category-ads-all", "outbound": "block" }
    ],
    "final": "proxy", // 默认情况下，所有其他流量都通过名为 "proxy" 的出站
    "auto_detect_interface": true // 自动检测出口网络接口，某些情况下需要
  }
}

将上述配置保存为 client_config.json，然后通过 sing-box run -c client_config.json 运行。之后，将需要代理的应用程序的 SOCKS5 代理设置为 127.0.0.1:1080 即可。

4.3. 主流图形化客户端 (GUI) 概览

对于不习惯命令行的用户，或者希望在日常设备上便捷使用代理，可以选择各种支持 sing-box 内核或其协议的图形化客户端。

桌面端 (Windows/macOS/Linux):
- GUI.for.SingBox (下一代 Clash Verge): 这是一款专为 sing-box 设计的图形化配置和管理工具，支持通过 GUI 创建和调整配置，管理配置文件（Profiles），最终生成 sing-box 可用的 config.json 。
- Nekoray / NekoBox: 广受欢迎的多协议客户端，支持 sing-box、Xray、Clash 等多种核心，界面友好，易于上手。
- Hiddify-Next: 另一款支持多种协议和 sing-box 的第三方 GUI 客户端。
- Clash Verge: 主要为 Clash 核心设计，但由于其配置范式与 sing-box 有相似之处，且社区活跃，部分衍生项目或新版本可能增强对 sing-box 的兼容性或提供类似体验。
移动端:
- Android:
  - Sing-box for Android (官方): 由 SagerNet 开发的官方 Android 客户端，功能全面，紧跟 sing-box 内核更新。
  - SagerNet: 也是 SagerNet 开发的一款支持多种协议（包括 sing-box 协议）的客户端。
  - NekoBox for Android: Nekoray 的 Android 版本，同样支持 sing-box 。
- iOS:
  - Sing-box for Apple (官方): 官方 iOS 客户端，提供原生体验。
  - Shadowrocket (“小火箭”): 老牌且功能强大的 iOS 网络工具，支持包括 Trojan, VLESS, Shadowsocks, Hysteria2, TUIC 在内的多种 sing-box 兼容协议。
  - Stash: 另一款流行的 iOS 代理客户端，以其强大的规则引擎和 sing-box 协议支持闻名。
  - Egern: 支持多种协议，包括 sing-box 的主流协议。
  - FoXray: 也被推荐用于 iOS 设备，支持 VLESS 等协议。

大多数图形化客户端都支持通过订阅链接（机场服务商提供）自动更新节点信息和配置，或者允许用户手动导入 sing-box 的 JSON 配置文件、单个节点的分享链接或扫描二维码添加节点。

近年来，通用型图形化客户端的兴起极大地简化了用户在多协议环境下的使用体验。诸如 Nekoray、GUI.for.SingBox、Hiddify 以及移动端的官方 sing-box 应用、Shadowrocket、Stash 等客户端，其设计目标就是兼容多种代理核心（如 sing-box, Clash, Xray）或 sing-box 所支持的广泛协议集。这种趋势的背后，是用户往往拥有运行不同协议的服务器，或者需要根据网络状况和特定需求灵活切换协议。为每种协议维护独立的客户端应用显然十分繁琐。通用客户端通过提供统一的用户界面，简化了配置管理（通常通过配置文件或订阅链接实现）和代理切换的流程。Sing-box 作为库或核心的能力，也为其被集成到这些第三方 GUI 客户端提供了便利。这意味着用户不再被束缚于单一协议的特定客户端，而是可以选择功能丰富、支持 sing-box 的图形化工具，从而更便捷地管理和使用其“科学上网”服务。

第五章：增强您的配置 (高级技巧)

在掌握了 sing-box 的基本安装和协议配置之后，可以进一步探索一些高级技巧，以增强代理服务的隐蔽性、稳定性和灵活性。

5.1. 使用 CDN 隐藏服务器 IP (例如 Cloudflare)

核心概念: 将代理服务器的流量通过内容分发网络 (CDN) 如 Cloudflare 进行中转，可以有效隐藏真实服务器的 IP 地址。这使得即使代理服务器的 IP 被直接探测或封锁，只要 CDN 节点可用，服务依然能够访问，从而提高了抗封锁能力。
工作原理:
1. 将您的域名解析指向 Cloudflare 的服务器（在 Cloudflare DNS 设置中开启橙色云朵代理）。
2. Sing-box 服务器配置为监听来自 Cloudflare IP 段的流量。
3. 客户端连接您的域名（实际上是连接到离客户端最近的 Cloudflare 边缘节点）。
4. Cloudflare 接收到流量后，再将其转发到您的源代理服务器。
必要条件:
- 一个您拥有的域名。
- 一个 Cloudflare 账户（免费套餐通常已足够）。
- 选择能够被 CDN 可靠代理的协议和传输方式。通常是基于 WebSocket (WS) 并通过 TLS 加密（通常在 443 端口）的协议，例如 Trojan + WS 或 VLESS + WS 。
Sing-box 配置示例 (客户端 Trojan + WS over CDN):

服务器端需要配置相应的 Trojan + WebSocket 入站。客户端出站配置如下：
```
{
  "outbounds":
}
```
注意：这里的 server 字段直接使用您的域名，因为 Cloudflare 会处理 IP 解析和转发。
服务器端注意事项:
- 服务器上的 sing-box 需配置为监听 WebSocket 流量，并使用与客户端一致的路径。
- 在 Cloudflare 的 DNS 设置中，确保对应域名的代理状态（橙色云朵）已开启。
- Cloudflare 的 SSL/TLS 加密模式建议设置为“完全”或“完全（严格）”，以确保从客户端到 Cloudflare 以及从 Cloudflare 到源服务器的全程加密。
益处:
- 显著提高抵抗 IP 直接封锁的能力。
- CDN 的全球节点分布可能（但不一定）为部分用户带来访问延迟的改善（对于动态代理流量，CDN 缓存效果有限，但其路由优化仍有一定作用）。

将 CDN 置于代理服务器之前，相当于引入了一个广受信赖的中间层。这种做法通常与 WebSocket 等能封装在标准 HTTP/HTTPS 请求中的传输协议配合使用。直接连接代理服务器 IP 的方式，一旦该 IP 地址被标记并封锁，服务即告中断。而 CDN 服务商（如 Cloudflare）拥有海量的 IP 地址资源，这些 IP 被大量合法网站共享。大规模封锁这些共享 IP 会造成巨大的“附带伤害”，审查机构对此通常较为谨慎。通过 CDN 传输的、使用 WebSocket 并以 TLS 加密的流量（尤其是在 443 端口），其外观与普通网站的 HTTPS 流量极为相似。CDN 在其边缘节点处理 TLS 握手，然后将流量（可能重新加密）转发至源服务器。这种方式不仅隐藏了真实服务器的 IP，还使得代理流量能够混入海量的、通过 CDN 的合法 HTTPS 流量之中，从而显著提升了抗审查的持久性。这对于在严格审查环境下维持代理服务的长期可用性是一项关键技术。

5.2. Sing-box 基础路由：智能分流流量

Sing-box 强大的路由功能允许用户根据多种条件精细控制流量走向，实现国内外分流、广告屏蔽、特定服务加速等目的。路由配置在 config.json 文件的 route 块中定义。

常用规则类型:
- 域名匹配: domain (精确匹配), domain_suffix (域名后缀匹配，如 google.com), domain_keyword (域名关键词匹配)。
- IP 匹配: ip_cidr (IP 地址段匹配), geoip (基于 IP 的地理位置，如 geoip:cn 匹配中国大陆 IP) 。
- 预设网站列表: geosite (匹配预定义的网站分类，如 geosite:google 匹配谷歌相关服务) 。
- 协议类型: protocol (如 dns 专门匹配 DNS 查询流量) 。
- 端口: port (匹配目标端口)。
- 进程名/包名 (客户端): process_name (Windows/Linux 进程名) 或 package_name (Android 应用包名)。

简单分流示例 (国内直连，国外代理):

{
  "route": {
    "rules":,
    "final": "proxy", // 所有未匹配上述规则的流量，默认通过名为 "proxy" 的出站 (即您的主代理出站)
    "auto_detect_interface": true // 建议开启，自动检测网络接口
  }
}

规则集 (rule_set): 为了方便管理大量的域名或 IP 列表，可以使用 rule_set 功能，引用预先编译好的规则文件（通常是 .srs 或 .db 格式）。这些规则集可以从远程 URL 下载更新。

5.3. 实现故障转移与基础负载均衡 (URLTest 和 Selector)

为了提高代理连接的稳定性和可用性，sing-box 提供了 URLTest 和 Selector 两种特殊的出站类型。

URLTest 出站 (自动选择最佳节点):
- 用途: URLTest 会定期测试一组预定义的出站代理节点，并自动选择其中延迟最低（或最先成功响应）的节点作为当前使用的出站9。这主要用于实现故障自动切换 (failover) 和基于延迟的简单负载均衡。
- 关键字段:
  - outbounds: 一个包含多个代理出站标签（tag）的列表，URLTest 将对这些出站进行测试。
  - url: 用于测试的 URL，例如 http://www.gstatic.com/generate_204 (谷歌提供的用于测试网络连通性的 URL，返回 HTTP 204 No Content)。如果为空，sing-box 有默认测试地址。
  - interval: 测试间隔时间，例如 "5m" 表示每 5 分钟测试一次。
  - tolerance: 延迟容忍度（毫秒），用于判断节点是否可用或切换的阈值。
- 示例:
```
{
  "outbounds":, // 参与测试的代理出站标签列表
      "url": "http://www.gstatic.com/generate_204",
      "interval": "5m", // 每5分钟测试一次
      "tolerance": 100 // 延迟容忍度 100ms
    }
  ]
}
```
  然后，在路由规则中（例如 route.final）使用 “auto-proxy-selector”作为出站。
Selector 出站 (手动选择节点):
- 用途: Selector 允许用户从一个预定义的出站列表中手动选择一个当前使用的出站。这种选择通常通过外部 API (例如 sing-box 的 Clash API 兼容接口) 进行控制，图形化客户端常利用此功能提供节点切换界面。
- 关键字段:
  - outbounds: 一个包含多个出站标签（可以是具体代理，也可以是 direct 或其他 URLTest 组）的列表。
  - default: 默认选中的出站标签。
- 示例:
```
{
  "outbounds":, // 可供选择的出站列表
      "default": "proxy-vless" // 默认选择 "proxy-vless"
    }
  ]
}
```
  同样，可以在路由规则中使用 “manual-proxy-selector”。

URLTest 和 Selector 为 sing-box 提供了强大的流量管理能力。URLTest 通过自动化的健康检查和延迟测试，确保了连接的韧性：当某个代理节点失效或表现不佳时，它能自动切换到其他可用节点，从而在无需用户干预的情况下维持“科学上网”的通畅。这对于故障转移至关重要。另一方面，Selector 则赋予用户明确的控制权，允许用户根据特定需求（如访问特定区域的地理限制内容，或临时切换到直连）主动选择出口。Clash API 的支持使得图形化客户端能够方便地集成这种手动选择功能。实际应用中，一种常见的模式是将多个 URLTest 分组（例如，一组美国服务器，一组日本服务器），然后使用一个 Selector 在这些分组或单个优质代理之间进行选择。这种组合既满足了自动化故障恢复的需求，也兼顾了用户的主动偏好。

第六章：故障排除与日常维护

即使配置无误，有时也可能遇到连接问题。了解如何排查故障和进行日常维护，是确保代理服务长期稳定运行的关键。

6.1. “芝麻开门”：通过 Sing-box 日志寻找线索

日志是排查问题的第一手资料。当遇到连接失败、速度缓慢或其他异常行为时，首先应该查看 sing-box 的日志。

服务器端日志: 如果 sing-box 作为系统服务运行 (通过 systemd 管理)，可以使用以下命令查看实时日志：
```
sudo journalctl -u sing-box -f --output cat
```
如果直接通过 sing-box run 命令在前台运行，日志会直接输出到终端，或者根据 config.json 中 log.output 的设置输出到指定文件。
客户端日志:
- 如果使用 sing-box 命令行作为客户端，日志同样会输出到终端或配置文件中指定的位置。
- 图形化客户端通常内置了日志查看器，方便用户查阅。
关注日志中的关键信息:
- 错误信息 (Error messages): 明确指示问题的发生，如连接超时、认证失败、证书错误等。
- 警告信息 (Warning messages): 可能提示潜在问题或配置不当。
- 连接尝试与结果: 可以看到客户端的连接请求、使用的协议、目标地址等。
- 路由决策: 对于复杂的路由配置，日志可以显示流量是如何根据规则被导向特定出站的。
- 日志级别 (log.level): 在 config.json 中，可以将 log.level 设置为 "debug" 甚至 "trace" 以获取更详细的诊断信息，但在正常运行时建议使用 "info" 或 "warn" 以避免日志过于庞大。

6.2. 配置检查：使用 `sing-box check` 进行预检

在修改 config.json 文件后，启动或重启 sing-box 服务之前，务必使用 sing-box check 命令校验配置文件的有效性：

sing-box check -c /path/to/your/config.json

该命令会检查 JSON 语法是否正确、字段名和值是否符合 sing-box 的规范。

sing-box check 命令是配置管理流程中不可或缺的“预飞检查”环节。JSON 格式对逗号、括号、引号等符号要求严格，而 sing-box 的配置项众多且可能存在嵌套，手动编辑时很容易出现笔误或使用了不正确的字段名。如果直接运行一个有错误的配置文件，可能导致 sing-box 服务启动失败、意外崩溃或行为异常。例如，某些 GitHub issue 中报告的崩溃问题，部分可能源于配置不当（提到的一个与 tun 配置相关的崩溃，如果涉及到需要 root 权限的资源访问，check 命令在尝试校验时或许能提前发现权限问题或配置冲突）。因此，在每次修改配置文件后、重启服务前，执行 sing-box check，可以及时发现并修正这些低级错误，从而节省大量的排错时间和避免不必要的服务中断。

6.3. 常见连接问题及其解决方案

防火墙阻挡端口:
- 症状: 客户端无法连接到服务器的指定端口。
- 排查: 仔细检查服务器的防火墙规则 (UFW, firewalld)，确保已为 sing-box 使用的协议和端口正确开放了 TCP 和/或 UDP 流量。
客户端配置错误:
- 症状: 连接失败，日志提示认证错误、地址错误等。
- 排查: 逐项核对客户端配置中的服务器地址、端口、用户ID (UUID)、密码、加密方法、传输参数（如 WebSocket 路径）、TLS SNI 等，确保与服务器端的入站配置完全一致。
TLS 相关错误 (适用于 VLESS, Trojan, Hysteria2, TUIC 等):
- SNI 不匹配: 客户端 tls.server_name 与服务器证书或 Reality/Trojan 期望的 SNI 不符。
- 服务器证书无效/过期: 检查服务器证书状态，及时续签或修复。
- 客户端无法验证服务器证书: 如果服务器使用自签名证书，客户端需要导入该证书或（不推荐，但可用于测试）设置 insecure: true。对于 Reality，确保客户端的 tls.server_name 与服务器 reality.handshake.server 一致。
DNS 解析问题:
- 症状: 可以连接代理，但无法访问网站，或特定网站无法打开。
- 排查:
  - 检查客户端和服务器 dns 配置块。
  - 确保代理服务器自身能够正常解析外部域名（可在服务器上用 ping 或 nslookup 测试）。
  - 客户端 DNS 是否正确通过代理或指定 DNS 服务器解析，避免 DNS 泄露。
  - 因 IPv6 偏好设置导致的 DNS 解析问题，提示注意 DNS 策略配置。
Reality 握手失败:
- 症状: VLESS+Reality 连接失败。
- 排查: 确认客户端的 public_key、short_id 与服务器端的 private_key、short_id 对应且正确。确认客户端 tls.server_name 与服务器端 reality.handshake.server 配置的域名一致。检查伪装的目标网站 (reality.handshake.server) 是否可访问且其 TLS 证书有效。
网络不可达 (“network is unreachable”):
- 症状: 日志中出现此类错误。
- 排查: 服务器可能已宕机，服务器 IP 可能被 ISP 封锁，或者存在网络路由问题。检查服务器状态和网络连通性。
时间同步问题:
- 症状: 某些协议（特别是依赖 TLS 和证书的）连接失败。
- 排查: 确保客户端和服务器的时间基本同步。在服务器上配置并启用 NTP 服务（sing-box 配置中也有 ntp 模块）。
服务器资源耗尽:
- 症状: 连接不稳定，速度极慢，服务频繁重启。
- 排查: 登录服务器检查 CPU、内存、带宽使用情况。如果资源不足，考虑升级 VPS 配置或优化 sing-box 配置（如限制并发连接数）。
Sing-box 进程崩溃 (panic):
- 症状: 服务意外停止，日志中出现 panic: 开头的错误信息和堆栈跟踪。
- 排查: panic 通常指示程序内部错误（bug）、不兼容的配置、或严重的资源问题 24。仔细阅读 panic 信息和相关的上下文日志。如果怀疑是 sing-box 的 bug，可以附上详细的日志、可复现的配置和操作步骤，到 sing-box 的 GitHub Issues 页面报告。

6.4. 保持更新：维护 Sing-box 及配置的有效性

网络审查技术和代理协议本身都在不断发展和演变。为了保持代理服务的有效性和安全性，需要进行持续的维护：

定期更新 Sing-box: 关注 SagerNet/sing-box 的 GitHub Releases 页面，及时将 sing-box 程序更新到最新的稳定版本。新版本通常包含 bug 修复、性能优化、安全更新以及对新特性或协议的支持。可以通过重新运行安装脚本或使用系统的包管理器进行更新。
关注社区动态: 留意 sing-box 的 GitHub Issues 、官方文档更新以及相关的技术社区和论坛。这些渠道通常会讨论最新的审查手段、协议的有效性变化以及新的规避策略。
更新路由规则集: 如果在路由配置中使用了 GeoIP、Geosite 等远程规则集，应确保这些规则集能够定期更新，以保证分流的准确性。部分客户端或辅助工具可能提供自动更新规则集的功能。

结论

Sing-box 作为一个强大且灵活的通用代理平台，为用户提供了构建自定义“科学上网”节点的坚实基础。通过本教程的指引，用户应能掌握从服务器准备、sing-box 安装、核心协议配置到客户端设置的完整流程。无论是追求极致隐蔽性的 VLESS+Reality、模仿 HTTPS 的 Trojan，还是经典高效的 Shadowsocks，亦或是面向特定网络优化的 Hysteria2 和 TUIC，sing-box 都能提供良好的支持。

然而，需要强调的是，网络审查与规避技术之间的博弈是一个持续动态的过程。今天有效的协议或配置，明天可能就会面临新的挑战。因此，保持学习的热情，关注技术前沿，并根据实际情况灵活调整策略，是确保长期顺畅访问互联网的关键。

最后，请负责任地使用本教程提供的知识和工具，遵守当地法律法规，并将其用于促进信息自由交流和个人学习研究等正当目的。

附录

A.1. Sing-box 常用命令行 (CLI) 命令参考

尽管 sing-box 的命令行参数和子命令的官方集中文档尚不完善，但通过分析其源码、社区讨论和实际使用，可以总结出以下常用命令：

核心操作:

sing-box run [options]

  : 运行 sing-box 实例。

  - `-c, --config <path>`: 指定一个或多个配置文件路径（JSON 或 SJSON 格式）。可以指定目录，sing-box 会加载目录内所有 `.json` 文件 22。
  - `-D, --directory <path>`: 指定配置文件目录，与 `-c` 配合使用。
  - `--disable-color`: 禁用彩色日志输出。

- ```
  sing-box check [options]

: 检查配置文件的有效性。

- `-c, --config <path>`: 同 `run` 命令。
- `-D, --directory <path>`: 同 `run` 命令。
- `--format`: 检查后自动格式化配置文件。

sing-box format [options]

  : 格式化（美化）配置文件。

  - `-c, --config <path>`: 指定输入配置文件。
  - `-D, --directory <path>`: 指定配置文件目录。
  - `-w, --write`: 将格式化后的内容写回原文件 5。
  - `-o, --output <path>`: 将格式化后的内容输出到指定文件。

- ```
  sing-box version

: 显示版本信息，包括构建标签 。



- `-n, --name`: 只显示版本名称。

密钥生成:
- sing-box generate uuid: 生成一个 UUID 11。
- sing-box generate reality-keypair: 生成 Reality 公私钥对 11。
- sing-box generate rand <length>: 生成指定长度的随机字符串（可用于密码）。
其他 (可能存在或特定构建中包含):
- sing-box geoip export <path>: 导出 GeoIP 数据。
- sing-box geosite export <path>: 导出 Geosite 数据。
- sing-box rule-set compile: 编译规则集。
- sing-box rule-set merge: 合并规则集。
通过 systemd 进行服务管理 (Linux):
- sudo systemctl start sing-box
- sudo systemctl stop sing-box
- sudo systemctl restart sing-box
- sudo systemctl enable sing-box
- sudo systemctl disable sing-box
- sudo systemctl status sing-box
- sudo journalctl -u sing-box -f --output cat 11

目前关于 sing-box 命令行工具的详细信息较为分散，可见于 GitHub issue 讨论 24、博客文章 19、官方文档的特定子页面 5 以及 Go 语言的源代码文件 22。尚无一个统一、详尽的“man page”式参考手册。上述列表整合了目前已知的主要命令及其功能，对于习惯使用命令行的用户而言，这是一个实用的快速参考。最准确和完整的参数列表，理论上可以通过 sing-box --help 或 sing-box <subcommand> --help 获取，但具体输出内容未在本次研究资料中直接提供。

A.2. 关键术语解释

CDN (Content Delivery Network, 内容分发网络): 一组分布在不同地理位置的服务器，用于缓存和加速网站内容的传递。在代理场景中，可用于隐藏源服务器 IP。
DPI (Deep Packet Inspection, 深度包检测): 一种网络数据包过滤技术，通过检查数据包的内容来识别协议类型、应用或特定数据模式，常用于网络审查。
GFW (Great Firewall, 防火长城): 指中国大陆用于互联网审查和内容过滤的一系列技术和行政手段的俗称。
GeoIP: 基于 IP 地址确定其地理位置的技术或数据库。
Geosite: 预定义的网站域名分类列表，常用于路由规则中对特定类型的网站进行分流。
Inbound (入站): Sing-box 中处理传入连接的配置模块。
Outbound (出站): Sing-box 中处理传出连接的配置模块。
Multiplexing (多路复用): 在单个网络连接（通常是 TCP 连接）上承载多个独立的逻辑数据流的技术，可以提高连接效率和并发性能。
QUIC (Quick UDP Internet Connections): 一种基于 UDP 的新型传输层网络协议，旨在提供比 TCP 更低的延迟和更好的拥塞控制，是 HTTP/3 的基础。
Reality: 一种 VLESS 协议的扩展，通过模拟真实网站的 TLS 握手来增强代理服务器的隐蔽性，抵抗主动探测。
SNI (Server Name Indication): TLS 协议的一个扩展，允许客户端在 TLS 握手初期就告知服务器其希望连接的域名，使得同一 IP 地址可以托管多个 HTTPS 网站。
TLS (Transport Layer Security, 传输层安全协议): 用于在两个通信应用程序之间提供私密性和数据完整性的加密协议，是 HTTPS 的基础。
UDP (User Datagram Protocol, 用户数据报协议): 一种无连接的传输层协议，提供快速但不可靠的数据传输。
UUID (Universally Unique Identifier, 通用唯一识别码): 一个128位的数字，用于在计算机系统中唯一地标识信息。在代理协议中常用作用户ID。
WebSocket (WS): 一种在单个 TCP 连接上进行全双工通信的协议，常用于 Web 应用。在代理中，可将流量封装在类似 HTTP 的连接中，便于穿透防火墙或通过 CDN。
XTLS-Vision: VLESS 协议的一种流控模式，旨在减少加密开销，提高性能。

A.3. 进一步学习资源

Sing-box 官方文档: https://sing-box.sagernet.org/ 5
Sing-box GitHub 仓库:(https://github.com/SagerNet/sing-box) 7
GUI.for.SingBox (图形化客户端):(https://github.com/GUI-for-Cores/GUI.for.SingBox) 56
Nekoray / NekoBox (图形化客户端):(https://github.com/MatsuriDayo/nekoray) (原版，新版可搜索 NekoBox)
Hiddify-Next (图形化客户端): https://github.com/hiddify/hiddify-next

0xdadream

https://0xdadream.github.io/2025/05/31/sing-box-da-jian-jie-dian/

本博客所有文章除特別声明外，均采用 CC BY 4.0 许可协议。转载请注明来源 0xdadream !

教程

Cloudflare代理配置端口

2025-05-31 网络

cloudflare

证书后缀

2025-05-25 服务器

证书

Sing-box 搭建您的专属科学上网节点实用指南

Sing-box 搭建您的专属“科学上网”节点实用指南

简介

Sing-box 简介：强大的通用代理平台

本教程目标

第一章：理解与安装 Sing-box

1.1. Sing-box 核心概念：构建代理节点的基石

1.2. 选择您的服务器 (VPS)：地理位置与操作系统考量

1.3. 在您的服务器上安装 Sing-box (以 Ubuntu/Debian 为例)

1.4. Sing-box 核心命令行工具 (CLI)

1.5. config.json 文件结构解析 (再探)

第二章：准备您的服务器环境

2.1. 基础服务器安全加固 (简述)

2.2. 防火墙配置：为代理协议开放端口

第三章：在 Sing-box 中配置热门协议

3.1. VLESS (配合 Reality 和/或 XTLS-Vision)

3.2. Trojan (配合 TLS，可选 WebSocket 传输)

3.3. Shadowsocks (重点关注 AEAD 2022 系列加密算法)

3.4. Hysteria2 (基于 QUIC，高性能)

3.5. TUIC (基于 QUIC，低延迟)

第四章：配置您的客户端设备

4.1. Sing-box 客户端通用配置原则

4.2. 使用 Sing-box 命令行作为客户端 (适用于高级用户或连接其他服务器)

4.3. 主流图形化客户端 (GUI) 概览

第五章：增强您的配置 (高级技巧)

5.1. 使用 CDN 隐藏服务器 IP (例如 Cloudflare)

5.2. Sing-box 基础路由：智能分流流量

5.3. 实现故障转移与基础负载均衡 (URLTest 和 Selector)

第六章：故障排除与日常维护

6.1. “芝麻开门”：通过 Sing-box 日志寻找线索

6.2. 配置检查：使用 sing-box check 进行预检

6.3. 常见连接问题及其解决方案

6.4. 保持更新：维护 Sing-box 及配置的有效性

结论

附录

A.1. Sing-box 常用命令行 (CLI) 命令参考

A.2. 关键术语解释

A.3. 进一步学习资源

你的赏识是我前进的动力

1.5. `config.json` 文件结构解析 (再探)

6.2. 配置检查：使用 `sing-box check` 进行预检