蓝牙 Mesh 越加中继，为什么反而越卡？
中继越多不一定越可靠。区分覆盖不足与重复流量，弄清 TTL、网络层重发与应用重试，用两组对照测试安排现场调优。
走廊尽头的灯偶尔不响应，你打开了附近几盏灯的中继功能。
效果似乎不错。于是，你索性把所有支持中继的灯都打开，再把重发次数往上调：“多转几次，总不会漏了吧？”
可一到整组调光，灯的反应又开始拖沓。有的先动，有的后动，手机上的状态还在刷新。
问题可能已经从“消息传不到”，变成了“同一片空口里，要发送的东西太多”。
中继能增加通信路径，但每一次转发也会占用无线资源。要判断下一步该加还是该减，先分清：你缺的是覆盖、备用路径，还是已经有太多重复流量。
上述场景是假设示例，不是实测记录。本文讨论以广播承载和 Managed Flooding（受控泛洪）为主的 SIG Mesh 网络，不代表所有蓝牙产品的实现。没有测量具体设备的时延、容量或成功率；排查顺序是工程建议。
AI 生成的空间示意插画；无线弧线不代表实测覆盖、信号强度或真实路由。
一、中继是帮消息换个位置发，不是把信号“加满格”
先看一条简单路径：
墙壁开关 → 走廊中继 → 远端灯。
开关直接够不到远端灯，但走廊里的节点能收到消息，再把它发出去。这就是中继有价值的地方：让消息跨过原本够不到的一段。
它没有把开关的发射功率变大，也没有给这条控制命令预留一条专用通道。
如果同一个房间里有许多启用 Relay 的节点，它们都可能接收到符合转发条件的消息，各自参与转发。多条路径能增加送达机会，却也意味着更多无线发送。
Bluetooth SIG 的网络设计文章和 Silicon Labs 的调优文档都强调了同一件事：中继要有位置、有用途，而不是看到设备支持，就全部启用。[1][2]
所以，“再加一个中继”之前，先问：
- 它能接上哪一段原本不稳定的链路？
- 它有没有提供不同于现有节点的备用路径？
- 它会不会被墙壁开关一起断电？
如果这几个问题都答不上来，你增加的可能主要是重复发送，而不是有效覆盖。
二、有重复包过滤，为什么还会忙？
一个容易产生的误解是：“Mesh 会过滤重复包，那中继再多也没关系吧？”
过滤能阻止某个节点反复处理已经见过的包，却不能让其他节点已经发出的无线信号消失。
比如 B、C 两个中继都收到 A 发来的消息。它们各自第一次接收时，都可能满足转发条件。D 后来收到来自 B 和 C 的副本，可以识别重复，但两次发送已经发生过了。
同时，还要区分两件事：
- 中继收到其他节点送来的重复副本，不应因此无限启动新的转发。
- 为提高可靠性，发送端或中继本身可能按配置发送多份副本。
前者由缓存等机制约束；后者是配置出来的重复发送。两者并不矛盾。SIG 的入门资料把 TTL 和消息缓存列为受控泛洪的约束机制；芯科文档另外说明了 Network Transmit 与 Relay Retransmit 配置。[2][3]
你先查什么？ 不要只看应用日志里“收到一条命令”。应用层只交付一次，并不能证明空口只发送了一次。结合协议栈计数、发送队列记录和可用的抓包工具，确认重复发生在哪一层。单个抓包点也可能漏包，不能直接当成整个网络的完整流量。
三、别把四个不同的旋钮，都叫“增强信号”
现场调参数时，最容易失去判断力的做法，是同时增加中继、提高 TTL、增加重发，再让应用多试几次。
这几件事作用不同：
| 调整项 | 主要改变什么 | 调整前先确认 |
|---|---|---|
| Relay 启用与部署位置 | 哪些节点参与转发，哪里有通信路径 | 是补盲区，还是在已有覆盖区增加重复转发？ |
| TTL | 消息允许跨越的跳数范围 | 控制对象在哪里，必要的备用路径需要多远？ |
| Network Transmit / Relay Retransmit | 源节点或中继在网络层的发送副本数量与间隔 | 当前 SDK 的字段表示重传次数，还是发送总次数？ |
| 模型发布、查询与应用重试 | 业务层产生多少消息、何时再次发送 | 是否存在高频上报、集中查询或重复提交？ |
TTL 尤其容易被误用。它限制消息传播范围，不是射频功率，也不是可靠性的百分比。TTL 为 0 的消息不会被中继；需要跨中继到达的设备，当然不能靠这样的消息覆盖。[3]
但也不能反过来，把 TTL 一律设大。“消息可以走得更远”不等于“眼前这盏灯更容易收到”。多余的传播还可能给其他区域增加负担。[1]
另外，配置界面上的“3”，可能代表三次发送，也可能代表三次重传。对应的初始发送是否另算，要查 SDK 接口和参数编码。没有弄清字段语义之前，先别照抄别人的数字。
四、怎么区分覆盖不足，还是消息太多？
不要只靠一次“刚才又好了”下结论。先用固定设备、固定位置和固定控制动作，做两组对照。
第一组：低负载下，问题是否仍固定出现在远端？
在测试环境中保留必要控制，降低可控的后台查询和上报负载。如果远端设备仍反复不可达，而改变一个有针对性的中继位置后明显改善，覆盖或路径问题值得优先检查。
这仍不是确诊：天线安装、遮挡、供电、配置错误等也可能影响结果。
第二组：设备位置不变，问题是否随着业务量增加而出现？
单次开关尚可，一开高频调光、批量查询或周期上报，就开始出现延迟。如果降低其中一类流量后表现改善，应该继续查空口负载、协议栈队列和网关处理能力，而不是立即再加中继。
Silicon Labs 明确提醒，模型发布频率过高会增加网络流量，造成响应迟缓。[2] 但“降频后变好”只能缩小排查范围，不能单凭这一点证明所有问题都是无线碰撞。
还有一个常被漏掉的检查：你测的是灯变慢了，还是状态回来得慢？
上一篇区分了发送端接受、设备模型状态和实际亮灯。调优时仍然要分别记录，否则可能拿“界面刷新慢”去调整本来没有问题的灯控链路。
五、真要调，按这个顺序留住证据
下面是一套可执行的联调顺序，不是协议规定的标准测试。
先保存基线。 记下固件与 SDK 版本、设备位置、中继开关、TTL、网络层重发、模型发布周期，以及控制端的查询与重试策略。导出配置时隐藏密钥。没有基线，就很难知道“变好了”究竟对应哪一次修改。
再给中继标用途。 在平面图上标出哪些负责跨房间、哪些负责走廊、哪些提供备用覆盖。先保留承担这些职责的节点，再分批评估覆盖高度重叠的中继。不要一口气关闭一大片，也不要靠远程配置把唯一管理路径切断；测试前留好现场恢复方式。
然后，一次只动一类变量。 先固定业务负载，比较中继配置；再固定中继布局，比较重复发送或发布频率。这样才能判断改动的影响。没有必要为了追求最低发送量，把可靠性冗余全部去掉。
最后，测忙时和故障时。 空闲时能控制，只完成了一半。还要在符合产品需求的调光、上报和查询负载下测试，并有计划地让一个承担中继的节点离线，再恢复。
每轮至少保留这些记录：
| 记录项 | 怎样记录才有比较价值 |
|---|---|
| 测试条件 | 相同位置、动作、负载与观察窗口，写明本轮只改了什么 |
| 控制结果 | 按“目标设备 × 控制动作”记录结果；状态未知单列，不混入已确认成功 |
| 响应时间 | 写清起点和终点：请求发出、模型状态返回，还是实际照明变化 |
| 慢响应与异常 | 保留样本数、较慢样本和失败位置，别只报平均值 |
| 备用路径 | 关键中继离线后哪些设备受影响，恢复后是否正常 |
如果要比较真实亮灯时间，需要合适的现场观察或测量手段；应用日志本身不能替代物理结果。
这一轮的目标，不是选出一个看起来最小的 TTL，或最少的中继数量。目标是在正常负载和约定故障条件下，保留足够可靠的路径，同时减少没有必要的发送。
六、是不是换成定向转发，就不用管这些了？
Bluetooth Mesh 还有 Directed Forwarding（定向转发）这一可选机制。它让参与特定转发路径的节点转发相关消息，而不是让所有符合受控泛洪条件的中继都参与，从而减少不必要的无线发送。[3]
但“协议里有”，不等于你手上的设备、SDK 和配置工具已经支持并启用。它也不能代替业务层的流量设计：如果应用不停生成新的控制、查询和重试，仍然需要检查这些消息是否必要。
对现有项目，更实际的第一步是列出当前真正启用的功能和参数，再决定是否值得引入新机制。不要在还没弄清瓶颈时，把升级协议版本当成修复结论。
下一次遇到“远处偶尔不响应”，先别把所有中继都打开。
先回答一个问题：这个新增中继，会补上哪一段路径？
如果问题只在忙时出现，再问另一个：这片网络里，哪些消息其实不必发这么多次？
相关阅读：从广播到多跳，需要补齐什么 · 电池节点为什么会等待下行消息
资料与适用范围
- Bluetooth SIG：How Bluetooth Mesh Networking puts the ‘large’ in large-scale wireless networks，2018-06-26。本文使用其 Relays、TTL、Network retransmissions 章节的设计原则，不沿用其中的示例规模、重传间隔或流量倍数作为产品指标。
- Silicon Labs：Bluetooth Mesh Networking Principles，11.0.2。用于核对中继密度、发布频率和网络层发送配置；具体接口与参数取值仍应查目标 SDK。
- Bluetooth SIG：The Bluetooth Mesh Networking primer，重点参考 4.18.1、4.19.2、4.19.3 节，核对 TTL、缓存、受控泛洪与定向转发。
资料核对日期：2026-11-06。本文未进行硬件测试，不提供通用最佳参数、固定节点容量或性能提升承诺。