代理协议怎么选
协议选择首先看两端实现、平台和网络路径，再看 UDP、多路复用、伪装和认证需求。配置字段见 出站总览 与各协议页。
完整配置
yaml
outbounds:
ss:
type: shadowsocks
server: ss.example:8388
method: none
password: ""
http:
type: http
server: http.example:8080
mux:
type: kyoukai
server: mux.example:443
password: change-me
choose:
type: selector
outbounds: [mux, ss, http]
default: mux
route:
final: choose
dns:
servers:
real: {type: udp, address: 1.1.1.1:53}
final: real定位
| 协议 | 适合 |
|---|---|
| Shadowsocks | 广泛互通，原生 TCP/UDP；插件和 2022 密钥按服务器写 |
| naive | Chrome 网络栈或 BoringSSL 的 HTTP/2 CONNECT，重视浏览器栈一致性 |
| SOCKS/HTTP | 通用前置代理或第三跳；可叠加 TLS/stream transport |
| AnyTLS | TLS 上的多路复用流，Linux BoringSSL |
| Kasumi | Noise 通道、原生 UDP、可配置记录分帧 |
| Kyoukai | mayami 自有 mux，XUDP/L3，适合两端都是 mayami |
| Mirage | REALITY/Kotodama 认证与 mux，Linux |
| Imina | HTTP/2 或 HTTP/3 POST，可选 Chromium 栈，Linux |
UDP
不写 udp 时由协议选择最好路径：Shadowsocks/Kasumi 原生，Kyoukai/Mirage 用 XUDP，Imina 用流内数据报，其余通常 over-tcp。经 detour 或 transport 时，原生 UDP 未必可达，应显式选 over-tcp/xudp。字段见 共享 udp。
互通与安全
同名协议不一定跨实现、跨版本完全互通。Kyoukai 第 2 版只承诺 mayami 两端；Mirage、Kasumi、Imina 的兼容范围也受版本和认证材料约束。链式或 CDN 路径不能替代协议自己的认证与端到端安全。
平台边界
AnyTLS、Mirage、Imina 以及部分 naive/TLS 能力依赖 Linux。当前 macOS 构建会明确拒绝这些后端，不会悄悄降级成明文。