TLS：一个块，不同能力的组合
mayami 的 TLS 客户端与服务端使用统一 YAML 语法，但平台、协议和引擎决定实际支持哪些字段。Linux 上可完整使用 BoringSSL；其他平台的 rustls 路径只接受信任设置，Chrome 指纹结论不能跨平台套用。
完整服务端配置
yaml
inbounds:
secure:
type: anytls
listen: 0.0.0.0:443
password: change-me
tls:
acme:
domain: proxy.example.com
outbounds:
direct:
type: direct
route:
final: direct
dns:
servers:
real: {type: udp, address: 1.1.1.1:53}
final: real服务端来源
tls 必须恰好选择一种来源：
certificate+key：已有证书链与私钥；文件变化可重新读取。acme：通过 TLS-ALPN-01 自动申请和续期。reality：以 REALITY 认证客户端，未认证连接转给 cover。kotodama：以 ECH 标签认证，未认证连接转给真实上游。
AnyTLS、naive、Mirage、Imina、Kyoukai 和可终止 TLS 的 SOCKS/HTTP/Mixed 入站各有自己的必填与适用子集。
客户端
客户端可配置引擎、SNI、证书名、根、insecure、证书/公钥钉子、ALPN、客户端证书、ECH、REALITY 和 Kotodama bundle。ca 与 insecure 互斥，客户端证书与私钥必须成对；钉子和 REALITY 还会排除普通信任设置。
指纹与 kTLS
“ClientHello 像 Chrome”不等于整条连接像 Chrome。HTTP/2 SETTINGS、TCP/IP 栈、时序、IP/SNI 一致性和流量形状仍是独立检测面。Linux 的普通 BoringSSL ClientHello 共用 Chrome 风格配置，但非 HTTP 协议有自己的 ALPN；REALITY 也有明确例外。
kTLS 方案经实测后未采用：内核记录层在 16 KiB 和小记录场景比用户态 BoringSSL 更贵。当前没有配置项，也没有自动交接路径。
平台边界
Linux 提供完整 BoringSSL、REALITY、Kotodama 和入站 TLS。DoQ/DoH3 及非 Linux 的 DoT/DoH 使用 rustls，只支持信任相关字段；显式给 SOCKS/HTTP 出站套 TLS 在非 Linux 会报错。