高延迟丢包链路
优先 QUIC 类协议
跨境链路常见 RTT 波动与丢包。Hysteria2 与 TUIC 基于 QUIC，在丢包环境下的表现通常优于基于 TCP 的方案：拥塞控制策略与连接迁移机制使单次丢包不至于触发整条连接重建。两者默认端口分别为 8443/udp 与 443/udp，后者便于在只放行 443 的网络中直接使用。
查看分流规则维度
01 · 镜像 tag
镜像版本与体积
四个 tag 覆盖试用、生产、边缘节点与排障四类需求。功能一致，差别在基础镜像、体积与调试信息。
| Tag | 用途 | 基础镜像 | 体积 | digest 前缀 |
|---|---|---|---|---|
| latest | 生产推荐 | Debian 12 slim | 约 86MB | sha256:9f2c… |
| v2.4.1 | 锁定版本可复现 | Debian 12 slim | 约 86MB | sha256:3ab7… |
| v2.4.1-alpine | 轻量、资源受限环境 | Alpine 3.20 | 约 41MB | sha256:71d4… |
| v2.4.1-debug | 含调试符号，仅排障 | Debian 12 | 约 214MB | sha256:c05e… |
digest 前缀仅用于快速比对镜像是否一致，完整值以仓库页面为准。校验方式与防钓鱼提示见 来源核验与防钓鱼；体积差异的原因见下方镜像瘦身与安全。
02 · 协议矩阵
协议 × 平台 × 默认端口矩阵
四个加速协议加两个显式代理入口，全部内置在同一个镜像里，无需额外组件。「默认端口」为容器内监听端口，宿主侧映射可自行指定。
| 协议 | Linux | Windows | macOS | 容器镜像 | 默认端口 |
|---|---|---|---|---|---|
| Hysteria2 | 支持 | 支持 | 支持 | 内置 | 8443/udp |
| TUIC | 支持 | 支持 | 支持 | 内置 | 443/udp |
| Shadowsocks-2022 | 支持 | 支持 | 支持 | 内置 | 8388/tcp |
| WireGuard | 支持 | 需驱动 | 支持 | 内置 | 51820/udp |
| SOCKS5 本地代理 | 支持 | 支持 | 支持 | 内置 | 1080/tcp |
| HTTP 代理 | 支持 | 支持 | 支持 | 内置 | 7890/tcp |
WireGuard 在 Windows 上需先安装驱动
WireGuard 依赖内核隧道能力：Linux 与 macOS 可直接使用系统内置实现，Windows 需要安装 WireGuard 驱动后才能建立隧道。镜像内置该协议，但 Windows 端未安装驱动时相关连接无法建立，表现为握手超时而非明确报错。
默认端口为容器内监听端口，映射到宿主机时可按需改写，避免与既有服务冲突。协议选定后由分流规则决定哪些连接走它，规则维度见 智能分流引擎。
03 · 选择建议
如何选择协议
协议选择取决于链路特征与合规要求，而不是性能排名。以下三类场景覆盖绝大多数部署。
内网与合规环境
走显式代理便于审计
SOCKS5 与 HTTP 代理把出口显式暴露为一个监听端口，所有经过的流量都有明确的接入点，便于在合规场景下做连接级审计与流量留痕。代价是每条连接多一跳本地转发，开销略高于隧道方案；适合审计要求优先于极限速度的环境。
查看多出口审计写法跨网段互通
需要底层隧道时选 WireGuard
当需求是让多个网段或多个节点之间建立可路由的通路，而不只是让容器出向流量走加速时，WireGuard 更合适：它提供的是三层隧道，可承载任意 TCP/UDP 流量与内网路由。注意在 Windows 端需先安装驱动。
查看按 IP 段分流
04 · 私有仓库
私有仓库与镜像同步
多数生产环境不会直接从公共仓库拉取镜像，而是同步到内网仓库统一分发。下面三个概念决定了同步能否稳定进行。
- registry endpoint
- 镜像仓库地址。部署清单中以完整地址加 tag 加 digest 的形式书写，例如 registry.example.com/kl/proxy:v2.4.1。使用私有域名时需确认节点可以解析该域名，且证书链完整。
- mirror 同步策略
- 从上游仓库到内网仓库的复制规则，通常按 tag 白名单同步。建议只同步固定版本 tag 与 latest，不镜像 debug tag，避免排障镜像扩散到生产节点；同步完成后校验 digest 与上游一致。
- 凭据配置方式
- 通过运行时的 secret 注入拉取凭据，例如 Kubernetes 的 imagePullSecrets。凭据只存在于节点运行时，不进入镜像层，也不写入部署清单；离线环境的镜像导入方式见 快连下载。
# 凭据从环境变量读取，避免出现在命令历史与 shell 记录中
$ docker login registry.example.com \
--username "$KL_REGISTRY_USER" \
--password-stdin < kl-registry-token.txt
# 按固定 tag 拉取，并核对 digest
$ docker pull registry.example.com/kl/proxy:v2.4.1
docker inspect --format '{{index .RepoDigests 0}}' registry.example.com/kl/proxy:v2.4.1
不要把凭据写进镜像或代码仓库
registry 凭据不得通过 ENV、ARG 或 COPY 进入镜像层：镜像层是可被导出的，凭据一旦进入层历史，即使后续删除文件也仍然存在。也不要把凭据写入 Dockerfile、Compose 文件或提交到代码仓库。一律使用运行时 secret 注入，并用只读凭据文件配合 --password-stdin 登录。
05 · 瘦身与安全
镜像瘦身与安全
四个 tag 的取舍集中在两点：边缘节点关心体积与内存占用，排障场景关心调试信息。安全基线则对所有 tag 一致适用。
两个特殊 tag 的适用边界
- v2.4.1-alpine
- 基于 Alpine 3.20，体积约 41MB，不到 Debian 版本的一半，适合边缘节点与 CI 构建机这类内存与磁盘受限的环境。差异来自基础镜像的系统库集合，协议支持与配置能力与生产镜像一致。
- v2.4.1-debug
- 基于 Debian 12 并保留调试符号，体积约 214MB。仅在需要崩溃栈回溯、符号化定位问题时临时使用，问题定位完成后应回到固定版本 tag，debug 镜像不应长期运行在生产节点。
安全基线
- 使用固定 tag 加 digest：部署清单同时记录两者，避免 tag 漂移导致实际运行版本与预期不一致。
- 非 root 运行：以非 root 用户启动进程，容器内不写入系统目录。
- 只读根文件系统：根文件系统设为只读，临时目录以 tmpfs 或 emptyDir 单独挂出。
- 关闭不需要的能力：只保留容器运行必需的 capability，其余全部移除；只暴露矩阵中实际使用的端口。
生产环境应该使用哪个镜像 tag？
生产环境建议使用 v2.4.1 这类固定版本 tag，并与 digest 一起记录在部署清单里；latest 便于试用但内容会随上游更新变化，无法保证可复现。资源受限的边缘节点可选 v2.4.1-alpine，体积约为 Debian 12 slim 版本的一半。
v2.4.1-alpine 和 v2.4.1-debug 有什么区别？
v2.4.1-alpine 基于 Alpine 3.20，体积小，适合资源受限环境；v2.4.1-debug 基于 Debian 12 并保留调试符号，体积较大，只用于排障取证。两者功能与生产镜像一致，区别只在基础镜像、体积与调试信息，不建议 debug 镜像进入生产。
WireGuard 协议在 Windows 上为什么标注为需驱动？
WireGuard 依赖内核隧道能力，Linux 与 macOS 可直接使用内置实现，而 Windows 需要安装 WireGuard 驱动或使用其官方客户端提供的隧道接口。因此镜像内置该协议，但在 Windows 端使用前必须先安装对应驱动，否则相关连接无法建立。
多协议同时启用会冲突吗？
不会。各协议的默认监听端口互不重叠，可以在同一容器内同时启用。但同一份分流规则只会选择一个出口，因此多协议并存的意义在于按出口分组：不同租户或不同工作负载可以分别指定走哪个协议，而不是让同一条流量同时经过多个协议。