翻墙基本原理：
翻墙是指突破网络审查（如中国的“防火长城”，即 GFW），让你能够访问被屏蔽的国外网站。其基本原理是通过加密和伪装你的网络请求，使其绕过防火墙的检测，并通过境外的中转服务器或代理服务器访问目标网站，然后将响应返回给用户。
以下为2025年最新且最常用的翻墙协议1) Shadowsocks是什么（高层）
Shadowsocks 是一种基于代理的翻墙工具，通常作为 SOCKS5 代理使用，通过加密的方式将网络流量从中国内地的设备转发到外部的代理服务器。其工作方式是通过**“代理”和“加密”手段隐藏真实流量，使其绕过防火墙。它通常需要配合Shadowsocks 客户端和Shadowsocks 服务器**进行使用。
工作原理（高级）
Shadowsocks 在客户端和服务器之间使用对称加密（如 AES 或 ChaCha20）加密流量，然后通过 SOCKS5 代理将加密后的流量发送到目标服务器。客户端负责将本地流量加密并通过代理服务器发送，服务器解密后转发请求。
Shadowsocks 的优点是简单易用、资源消耗较低，因此曾广泛应用于翻墙。
适合场景
原本适用于对隐蔽性要求不高、简单翻墙需求的场景（如访问普通网站、绕过局部网络限制）。
但随着 GFW 的升级，它现在被认为易于检测和封锁，尤其是在主动封锁机制（如深度包检测，DPI）下。
优点
缺点
随着防火墙技术的进步，Shadowsocks 已经变得容易被 DPI 检测到。
缺乏内置的隐蔽性，容易被识别为常见的代理流量（特别是通过流量特征分析）。
在某些封锁较严格的环境中（如中国大陆），其被封锁的风险极高。
为什么不推荐使用
2) VMess是什么（高层）
VMess 是 V2Ray 系列中的核心协议之一，设计上为比 Shadowsocks 更复杂和灵活的协议，它支持多种传输层（TCP、WebSocket、HTTP2 等），并且引入了认证机制（如 UUID、加密方式等）。原本用于绕过 GFW，但随着技术演进，现已不再是最优选择。
工作原理（高级）
VMess 的工作机制类似于 Shadowsocks，但它加入了更强的认证机制和更复杂的加密算法（如 AES）。它通过 请求头加密 和 多重传输方式（如 WebSocket、gRPC） 来隐藏流量特征，理论上比 Shadowsocks 更加隐蔽。
VMess 可以配置多种传输方式（如 TCP、WebSocket、HTTP2 等），让数据通过这些方式传输，从而躲避深度包检测。
适合场景
本来适合需要多传输协议或更强认证的场景（例如公司内部的远程访问或自建 VPN）。但是，VMess 协议在高强度防火墙下已经逐渐显现出易被检测和封锁的缺点。
优点
缺点
为什么不推荐使用
3)AnyTLS是什么（高层）
AnyTLS 是一种把任意后端代理流量“封装/打包”到 TLS 会话中的传输方式，常见于 sing‑box 等现代代理核心中，用来简化 TLS 伪装并提供会话管理。它不是一个独立的底层协议标准，而是对“通过 TLS 隧道承载任意后端协议”的一种实现/配置模式。
sing-box.sagernet.org+1 工作原理（高级）
客户端与服务器建立标准的 TLS 连接，所有后续的代理请求在该 TLS 会话中传输；服务端在 TLS 解包后将请求转发至对应后端（比如 VLESS、Trojan、Shadowsocks）。AnyTLS 常提供会话复用、心跳、空闲回收等管理功能以提升稳定性和并发效率。
sing-box.sagernet.org 适合场景
想把流量伪装为普通 TLS（HTTPS）且又需要承载多种后端协议、或在资源受限（无法做完整 HTTP 伪装）时的部署选择。
优点
缺点
部署注意
4)VLESS是什么（高层）
VLESS（VMess Less）是 V2Ray/XRay 生态中的一种轻量认证传输协议：
认证基于 UUID，协议本身不自带加密（通常依赖 TLS/底层传输提供加密）。它被设计为更简单、开销更低的替代 VMess。
xtls.github.io+1 工作原理（高级）
客户端使用配置好的 UUID 等凭证向服务端发起连接，VLESS 负责会话建立和（可选的）多路复用，但具体的加密/伪装通常依赖外层传输（如 TLS、WebSocket+TLS、gRPC 或 Reality）。因此，VLESS 常与 TLS 或其他伪装层组合使用以保证安全与隐蔽性。
xtls.github.io+1 适合场景
需要
低延迟、高并发和
灵活传输选择的自建节点（例如面向开发者或技术用户的自托管服务）。适合将认证与传输层分离的架构。
GitHub 优点
极其灵活：可以挂载在多种传输（WS/TLS、gRPC、Reality 等）上。
GitHub
缺点
部署注意
5)Trojan是什么（高层）
Trojan 是一种把代理流量尽可能模拟成普通 HTTPS 的设计思路/实现，目标是让被检测方难以区分正常 HTTPS 与 Trojan 代理流量。它基于标准 TLS，通常通过密码或证书作为鉴权手段。
trojan-gfw.github.io+1 工作原理（高级）
客户端与服务端建立一个看起来像 HTTPS 的 TLS 连接；在 TLS 层通过预共享密码或证书来鉴权，经过鉴权后再传输代理数据。由于外观与行为接近真实 HTTPS，Trojan 在被动检测下通常更“隐蔽”。
trojan-gfw.github.io 优点
缺点
部署注意
6)Hysteria2（通常简称 Hysteria，二代规范为 Hysteria2/Protocol v2）是什么（高层）
Hysteria（及 Hysteria2）是基于 QUIC/HTTP/3 的高性能代理协议，设计目标是
在高丢包/高延迟环境下仍保持良好体验，并支持 UDP 转发与 TUN/TProxy 等高级功能。它将流量伪装为 HTTP/3 风格以增强抗封锁能力。
GitHub+1 工作原理（高级）
Hysteria 在 QUIC（用户态 UDP 的可靠传输）之上实现代理协议，利用 QUIC 的流与连接管理、拥塞控制与 0‑RTT 能力改善延迟与丢包恢复；同时对上层流量进行一定伪装，使其与 HTTP/3 流量相似，降低被主动封锁的可能。
v2.hysteria.network+1 适合场景
对实时性/丢包敏感的场景（游戏、视频、VoIP、移动网络）和需要 UDP 转发的用途。适合网络条件差但能允许 UDP 通信的环境。
GitHub 优点
缺点
部署注意
7)TUIC是什么（高层）
TUIC（Delicately‑TUICed 等实现）是为 QUIC 代理场景标准化的一套协议规范，目标类似 Hysteria：利用 QUIC 的优势（0‑RTT、连接迁移、多路复用）来实现高性能、抗丢包的代理。它在实现细节上与其他 QUIC 代理（Hysteria）存在差异，并提供自己的实现生态。
GitHub+1 工作原理（高级）
基于 QUIC 的可靠传输与连接特性，TUIC 规范定义了如何在 QUIC 之上封装代理请求、认证与多路复用，以便实现低延迟与连接迁移等能力（例如客户端网络切换时保持会话）。
GitHub 适合场景
需要 QUIC 特性的部署者（0‑RTT、连接迁移、低延迟、UDP/实时应用场景），并且能够控制客户端/服务端实现版本匹配的环境。
GitHub 优点
能利用 QUIC 的现代特性（0‑RTT、迁移、多路复用），在移动场景和高丢包环境表现好。
GitHub
缺点
实现间兼容性可能成为问题（不同实现/版本差异）。
GitHub同样受限于网络对 UDP/QUIC 的支持策略。
部署注意
简明对比（快速决策参考）
发表于