客户端指南

Clash/Mihomo 的 tcp-concurrent 会叠加网速吗？它只抢先连接可用 IP

解释 Mihomo tcp-concurrent 如何尝试 DNS 返回的多个 IP，以及它为什么不是在多个代理节点间分流或叠加带宽。

发布于 2026/8/28 · 更新于 2026/8/28 · 2 项可核验来源

先看重点`tcp-concurrent` 不会把多条节点带宽合并。Mihomo 官方定义是：对 DNS 返回的所有 IP 尝试连接，采用最先成功的一条。它影响的是建连等待，不会让一条下载同时使用多个代理节点；只有同一目标解析出多个 IP、其中部分地址连接慢或不可达时，才可能更快建立连接。

配置里多了一行 tcp-concurrent: true，连接日志又在短时间内出现同一域名的多个 IP，很容易把它理解成“同时跑几条线路”。名字确实像加速开关，实际做的事窄得多。

它并发尝试的是一个域名解析出的多个 IP，最先成功的连接会被采用。 这里没有把流量拆到多个机场节点，也没有把几条线路的带宽相加。

它并发的是地址，不是机场节点

一个域名可以同时返回多个 IPv4 或 IPv6 地址。这些地址看起来属于同一个服务，当前位置到它们的路径却可能不同：某个地址很快建立连接，另一个地址可能超时或暂时不可达。

Mihomo 当前全局配置文档对 tcp-concurrent 的定义很直接：使用 DNS 解析出的所有 IP 进行连接，采用第一个成功的连接。由此能确认的是建连候选和选择结果，不能推出多条成功连接会共同传输后续内容。

几个容易混淆的名字可以这样分：

所以，tcp-concurrent 不是“负载均衡的另一种写法”。后两者决定用哪个代理节点，前者处理一次连接面对多个解析地址时的等待。想区分多节点分配，可以看负载均衡为什么会换出口 IP。

这里的 concurrent 也不是机场套餐写的“并发连接数”。后者限制账户同时存在的连接或设备使用，属于服务规则；两者只是中文里都出现了“并发”。具体限制可对照设备数、在线 IP 数和并发连接数的区别。

假设目标域名返回 A、B 两个地址。A 当前不可达，B 正常；若程序只等 A 失败后才试 B，用户会先承受一次超时。并发尝试让 B 有机会更早完成连接，卡顿可能缩短。

IETF 的 RFC 8305 也讨论了相近的通用问题：域名常有多个地址，不同地址族或路径可能损坏、受阻或性能不佳，并行推进连接候选可以减少用户看到的等待。它描述的连接尝试会错开启动，并建议在一个连接建立后取消其他未完成尝试。

这份 RFC 用来解释“为什么竞速连接有用”，不代表 Mihomo 完整采用了 RFC 8305 的地址排序、间隔或取消细节。Mihomo 对这个开关公开承诺的范围，仍应以自己的文档为准。

连接成功以后，一条下载能跑多快，仍受节点带宽、丢包、拥塞、目标站限速和线路质量影响。tcp-concurrent 没有把已选连接变成多路传输，也不会把 100 Mbps 和 200 Mbps 两条节点拼成 300 Mbps。

如果问题是“第一次打开偶尔要等很久”，而同一目标确实有多个解析地址，这个开关可能与等待有关。若网页已经顺利打开，只是视频缓冲或大文件速度低，继续改并发连接通常偏离了问题；此时更该看低延迟节点为什么仍然很慢中的带宽、丢包和目标路径。

策略组测速整组变红是另一个问题，不要把“打开 TCP 并发”当作修复所有超时的按钮；可转到节点全部超时的分层排查核对测试与真实连接。

配置和客户端当前工作正常时，没有必要因为别人的模板写着“网络优化”就额外加入。只有一次连接面对多个解析地址时，这个字段才有候选可选。

若同一网络下反复出现某个多 IP 域名首次连接卡住，而换网络或直接指定另一个地址后现象消失，可以把 tcp-concurrent 当作单一对照变量。比较时保持节点、目标、DNS 和客户端版本一致，只看首次建连是否稳定变化；不要一边换节点、改 DNS、升级内核，一边把结果归给这个开关。

开启后问题没有变化，原因就应回到实际失败层：

官方资料没有承诺打开后能缩短多少毫秒。没有同一网络、同一目标的前后记录时，把它当作一项建连策略说明即可，不把配置开关写成实测加速结果。

以下来源于 2026/8/28 复核。版本、支持平台和发布状态以后续官方页面为准。

持续更新

想收到新文章，可以关注 TG 频道；发现下载失效、套餐变化或步骤不一致，请附上页面链接和可公开的截图。不要发送订阅链接、密码或完整账户信息。

读者互动

— 次访问— 累计日独立访问— 条评论