---
url: /manual/tls.md
description: TLS 客户端、服务端、ACME、REALITY、Kotodama 与指纹边界
---

# TLS：一个块，不同能力的组合

mayami 的 TLS 客户端与服务端使用统一 YAML 语法，但平台、协议和引擎决定实际支持哪些字段。Linux 上可完整使用 BoringSSL；其他平台的 rustls 路径只接受信任设置，Chrome 指纹结论不能跨平台套用。

## 完整服务端配置

```yaml check
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 客户端](/configuration/shared/tls-client) 与 [TLS 服务端](/configuration/shared/tls-server)。

## 服务端来源

`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 更贵。当前没有配置项，也没有自动交接路径。

::: info 平台边界
Linux 提供完整 BoringSSL、REALITY、Kotodama 和入站 TLS。DoQ/DoH3 及非 Linux 的 DoT/DoH 使用 rustls，只支持信任相关字段；显式给 SOCKS/HTTP 出站套 TLS 在非 Linux 会报错。
:::

## 相关

* [共享 TLS 客户端](/configuration/shared/tls-client)
* [共享 TLS 服务端](/configuration/shared/tls-server)
* [protocols](/manual/protocols)
* [limits](/manual/limits)