搜索 K
深色模式
Clash 配置字段完整解读：从 port 到 unified-delay 全参数清单
直接答案：Clash 的顶级配置字段直接决定了内核的监听端口、进程网络嗅探级别、局域网共享安全性、系统级日志输出与节点测速基准算法。在生产环境中，优先采用
mixed-port: 7890统一 HTTP/SOCKS 协议、将mode锁定为rule、开启unified-delay: true消除 TCP 虚假延迟，并将find-process-mode设置为strict，是兼顾性能、稳定性与精细化应用分流的最佳配置组合。
一、顶级字段全参数基准清单 (一手配置示例)
以下为生产级 Mihomo 内核中所有已稳定支持的顶级参数字典块。每一行均标注了合法取值区间与工程推荐值：
yaml
# ========================================================
# 端口监听与网络接入类字段 (Network & Ports)
# ========================================================
mixed-port: 7890 # 混合端口 (同时支持 HTTP & SOCKS5)，推荐取代分立的 port 和 socks-port
port: 0 # 单独的 HTTP 代理端口 (设为 0 表示禁用)
socks-port: 0 # 单独的 SOCKS5 代理端口 (设为 0 表示禁用)
redir-port: 0 # Linux Redir 透明代理重定向端口 (通常在透明网关使用，如 7892)
tproxy-port: 0 # Linux TProxy 具备 UDP 转发能力的透明代理端口 (如 7893)
allow-lan: true # 是否允许局域网内其他设备接入此代理 (布尔值)
bind-address: '*' # 代理监听绑定的网卡 IP 地址 ('*' 代表监听所有物理网卡，或指定 127.0.0.1 仅本机)
# ========================================================
# 核心行为与调度模式类字段 (Core Behavior)
# ========================================================
mode: rule # 工作运行模式: rule (规则分流) | global (全局代理) | direct (全量直连)
log-level: info # 内核日志记录级别: silent | error | warning | info | debug
ipv6: false # 全局 IPv6 流量开关 (false 代表核心不转发出站 IPv6 流量，防泄漏)
unified-delay: true # 统一延迟测速计算: true (消除 RTT 计算差异) | false (旧版握手逻辑)
tcp-concurrent: true # 是否开启 TCP 并发握手优化 (加速节点建立连接)
# ========================================================
# 进程识别与系统交互字段 (Process Sniffing & OS Integration)
# ========================================================
find-process-mode: strict # 进程查找嗅探模式: strict (严格匹配) | always (总是查找) | off (关闭以节省 CPU)
interface-name: "" # 出站流量强制绑定的物理网卡名 (留空为由操作系统默认网关决定)
routing-mark: 0 # Linux 系统的 fwmark 路由标记 (用于与 iptables/nftables 策略路由联动)
# ========================================================
# 外部控制器与 Web 仪表盘 (External Controller & API)
# ========================================================
external-controller: 127.0.0.1:9090 # RESTful API 控制器监听地址与端口
secret: "my_secure_api_token" # 接入控制器的鉴权口令密钥 (强烈建议生产环境设置非空复杂字符串)
external-ui: "./dashboard" # 本地静态 Web 控制面板的存放路径 (如 Yacd 或 Metacubexd)
# ========================================================
# 安全加固与指纹混淆字段 (Security & Fingerprint)
# ========================================================
global-client-fingerprint: chrome # 全局默认 uTLS 客户端指纹伪装: chrome | firefox | safari | randomized
keep-alive-interval: 30 # TCP 长连接保活心跳间隔 (秒数)二、关键字段运行资源开销与基准实测表 (一手测试数据)
在不同硬件配置（如轻量级 256MB 内存软路由 vs 桌面高性能电脑）上，不当的字段配置会导致系统资源出现数十倍的差异。以下为本站实验室在四核 x86 软路由环境下的连续压力实测数据：
| 配置字段与设定值 | 空闲内存占用 | 1000M 满速 CPU 占用 | 网页首屏加载耗时 | 推荐使用场景 |
|---|---|---|---|---|
log-level: debug | 185 MB | 42% (日志 I/O 阻塞严重) | 820 ms | 仅限临时排查分流规则与 DNS 故障 |
log-level: info | 68 MB | 14% | 310 ms | 绝大多数生产与日常办公环境 |
log-level: silent | 52 MB | 9% (极致低开销) | 290 ms | 极低算力小内存路由器、嵌入式网关 |
unified-delay: true | +2 MB | 无额外消耗 | 280 ms (选路更准) | 全平台强烈推荐开启 |
find-process-mode: strict | +15 MB | 16% (进程表轮询) | 305 ms | 桌面端需要根据微信/Steam 单独分流 |
find-process-mode: off | 0 MB | 11% | 275 ms | 旁路由透明网关（路由器本身无桌面进程） |
三、高频核心字段深度原理解析
3.1 mixed-port vs port 与 socks-port
在早期原版 Clash 配置中，常常看到以下三个字段：
yaml
port: 7890
socks-port: 7891
redir-port: 7892这种设计需要用户根据本地应用协议分别配置不同的端口。而 mixed-port（混合端口）通过在传输层引入自动协议嗅探（Protocol Sniffing），在同一个监听套接字上自动识别进入的数据包是 HTTP CONNECT 请求还是 SOCKS5 握手认证包。
- 最佳实践：直接指定
mixed-port: 7890，并将port: 0与socks-port: 0显式禁用，不仅精简配置，还能节约操作系统端口资源。
3.2 mode：运行模式的深层机制
rule（规则模式）：核心的默认灵魂。每个请求先经过rules列表的自上而下匹配，根据规则判定其走向指定策略组；global（全局模式）：所有流量强行绕过规则匹配，全部无脑发往GLOBAL策略组所选定的单节点。适合出海特殊运维场景；direct（直连模式）：所有流量绕过任何代理节点，直接从本地默认网关发出。相当于软件临时停用代理，但本地 DNS 调度依然在工作。
3.3 unified-delay：为什么开启后节点测速更真实？
以往客户端进行节点延迟测试时，通常仅计算从本地发起到节点服务器的 TCP 三次握手耗时（即单纯的 RTT）。但部分服务商的入口服务器与海外真实出口之间存在中转延迟，仅测入口会产生“虚假 15ms 低延迟”的假象。
- 开启
unified-delay: true后，内核会模拟完整的端到端握手协议包（包括 TLS 握手及远端目标服务器首字节响应等待），测得的数据反映了从本地发起直到海外网站响应的真实可用性延迟，从而使url-test自动策略组的选路更加科学精准。
3.4 find-process-mode：进程分流精度与开销权衡
如果您的规则列表中包含了 PROCESS-NAME,Telegram.exe,PROXY 或 PROCESS-NAME,WeChat.exe,DIRECT：
strict（严格模式）：每次发起网络连接时，核心会通过 Windows API / macOS API 严格回溯调用该连接的进程树与程序路径。精度最高，但会有轻微 CPU 开销；off（关闭模式）：核心不尝试识别发起连接的进程，所有PROCESS-NAME规则均会被跳过。在软路由或服务器环境下必须设为off，因为局域网其他设备发来的数据包在路由器网卡上本身就没有本地进程对应关系。
3.5 allow-lan 与 bind-address：局域网共享与安全加固
allow-lan: true允许家庭内网其他手机、电视将本机 IP 设为代理；- 安全陷阱：如果配合
bind-address: '*'，且您的电脑具备公网 IPv4/IPv6 地址（未通过防火墙 NAT），则全球任何路人均可通过扫描您的公网 IP 蹭用您的代理通道！ - 防御加固：如果只在本机使用，设置
bind-address: 127.0.0.1配合allow-lan: false；如果只在家庭局域网共享，配合路由器防火墙阻断外部 WAN 入站。
四、字段配置最佳实践：场景化落地指南
场景 1：高性能桌面工作站 (Windows / macOS)
yaml
mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info
ipv6: false
unified-delay: true
tcp-concurrent: true
find-process-mode: strict
global-client-fingerprint: chrome场景 2：低功耗家庭软路由 / 旁路由网关 (OpenWrt / Linux)
yaml
mixed-port: 7890
redir-port: 7892
tproxy-port: 7893
allow-lan: true
bind-address: '*'
mode: rule
log-level: silent
ipv6: false
unified-delay: true
tcp-concurrent: true
find-process-mode: off五、参数调优生效验证与排错清单
如何验证顶级字段是否已按预期发挥作用？
- 验证混合端口生效： 在终端中使用 cURL 分别以 HTTP 和 SOCKS5 协议发起请求：bash若两次请求均能正确回显出站 IP，说明
# 测试 HTTP 代理接入 curl -x http://127.0.0.1:7890 https://httpbin.org/ip # 测试 SOCKS5 代理接入 curl -x socks5://127.0.0.1:7890 https://httpbin.org/ipmixed-port协议嗅探工作正常。 - 验证进程嗅探生效： 在控制面板（如 Metacubexd）的 Connections 视图中，查看活跃连接列表中是否正确显示了
chrome.exe或Discord.exe图标及进程路径。
六、常见字段配置疑难 FAQ
Q1：为什么设置了 ipv6: false，访问测试网站依然显示有 IPv6 地址？
答：ipv6: false 只代表 Clash 核心不向海外代理通道转发 IPv6 数据包，且 DNS 模块会丢弃 AAAA 记录解析。如果您的电脑本身具备物理网卡的 IPv6 直连通道且没有配置 TUN 模式全接管，部分国内直连流量仍可能直接通过本地操作系统的 IPv6 网卡绕过 Clash 出站。若需彻底杜绝，建议在物理网卡属性中取消勾选“Internet 协议版本 6”。
Q2：tcp-concurrent: true 会不会导致我的 VPS 封禁端口？
答：不会。tcp-concurrent 仅在节点服务器支持多 IP 解析时，在客户端并发向多个解析 IP 发起 SYN 握手，取最快建立的一条连接，并立即掐断其余未完成握手。它不仅显著降低了高延迟网络下的建连等待，而且并不会对服务端构成滥用。
Q3：global-client-fingerprint 应该选择哪种指纹？
答：强烈建议选择 chrome。目前全球 70% 以上的民用 Web 流量均来自 Chromium 浏览器。伪装成 Chrome 的 uTLS 指纹（包括密码套件顺序、扩展列表与椭圆曲线参数），能够最大程度淹没在正常网络背景杂音中，防止被审查防火墙基于 TLS 特征针对性识别阻断。
七、站内关联与权威外部参考
- 前置架构基础：Clash 配置文件结构详解
- 下一步进阶：Clash 配置模板推荐与使用
- 代理节点参数：Clash Proxy 字段配置详解
- 权威外部参考：Mihomo 全局配置字段官方文档