开始之前：先理解会议为什么那么"娇气"
先讲一个很多人有过的经历。有用户反馈说，他平时看 4K 视频、传几个 G 的工程文件都没问题，唯独开视频会议的时候老是断断续续——对方总说"你声音有点卡"、"画面糊了一下"。他以为是网速不够，去测速发现带宽很充足，这就奇怪了。
问题出在"场景特性"上。视频会议和看视频、下载文件，对网络的要求完全不同：
能容忍延迟，怕的是带宽不够
带宽要求不高，怕的是延迟和抖动
这就是为什么测速带宽充足，会议照样会卡——会议要的不是"路够宽"，而是"路够稳"。下面五个设置，全都是围绕"稳"这个字做的。
五步自查清单，会前十分钟过一遍
下面这五项，按"从易到难"的顺序排列。前两项是基础，所有人都会受益；后三项是进阶，适合经常开会的用户逐项对照。每一项都给出明确的操作路径和判断标准，你不需要记，照着做就行。
设置一：确认会议流量走的是加速通道
这是最容易出问题、也最容易被忽略的一项。开了 QuickQ 不等于"所有流量都加速了"——智能分流的设计逻辑是只加速需要加速的部分，而会议软件有时候会被分流的识别规则"误判"。
检查智能分流是否把会议应用包含在内
会议软件没走加速通道，等于白开 QuickQ打开 QuickQ 客户端，进入"智能分流"设置，查看当前的分流规则。规则通常按应用类型或域名划分，你需要确认：你常用的会议软件（比如 Zoom、Teams、Google Meet、腾讯会议海外版等）是否被列在"走加速"的那一侧。
如果不在，把它添加进去；如果不确定，可以先临时关闭智能分流，让所有流量都走加速通道——这是最简单的验证方式。等会议结束后再重新开启分流。
怎么判断"会议到底有没有走加速"？
有两种办法。第一种是在会议进行时打开客户端，看实时流量曲线——如果会议期间有持续稳定的流量波动，说明流量正在走 QuickQ。第二种更直接：先不开 QuickQ 加入一次会议，记下体验；再开着 QuickQ 加入同样配置的会议，对比一下。如果开着明显更稳，那就说明加速起作用了。
关于"误判"：分流系统按域名和应用特征识别流量。有些会议软件的流量特征比较特殊，或者服务器地址经常变化，就可能被漏掉。这也是为什么要定期检查分流规则——软件更新一次，识别规则可能就需要更新一次。
设置二：选一个"稳定优先"的节点
会议场景对节点的要求，和下载、看视频完全不一样。下载看带宽，会议看稳定。一个带宽很大但波动明显的节点，看视频没问题，但开会就会出状况。
优先选负载低、离会议服务器近的节点
不是选延迟最低的，而是选"最稳"的选节点时，重点看两个数字：负载和延迟。负载比延迟更重要——负载高的节点，即使延迟数字好看，实际使用时会因为排队而抖动加剧。会议的推荐标准是：负载低于 40%、延迟在 80ms 以内。
另外，考虑一下你的会议服务器在哪。如果对方用的是欧洲或美国的会议服务，选一个靠近那个区域的节点会更好。因为完整路径是"你 → 节点 → 会议服务器"，两段都顺才是真的顺。
如果常用某个节点，可以固定下来
如果某次会议体验特别顺畅，可以把这个节点固定下来。QuickQ 支持在客户端里对某个节点"置顶"，方便下次快速切换。固定节点的好处是：每次都走同一条线路，稳定性可预期，不会因为自动选路的实时调整而引入意外的波动。
别在会议中切节点：虽然在 3.0 版本之后切换节点已经能做到不断流，但会议对"连接波动"依然是最敏感的。如果会议中途感觉卡了，先观察十秒，实在不行再切——切完给系统几秒钟稳定下来。
设置三：把设备的本地资源留够
这一项和 QuickQ 无关，但经常是会议卡顿的真正元凶。会议软件在做的事情，比你想象的要多：同时处理音频编码、视频编码、回声消除、背景降噪、画面渲染，每一件都吃 CPU。如果此时你的设备还在跑别的重负载应用，会议软件就会被"饿"到。
会前关闭不必要的后台程序和下载任务
把设备的"算力"和"带宽"都留给会议开会前五分钟，做三件事：
网盘同步、系统更新、大文件下载，这些任务会在后台偷偷占用带宽。它们不一定能把带宽占满，但会带来"突发流量"，干扰会议的稳定。
强烈建议现代浏览器每个标签页都可能是一个独立进程。开着几十个标签页的时候，CPU 和内存都在被持续占用，会议软件的音视频处理会因此变慢。
强烈建议很多笔记本在电池模式下会自动降频，CPU 一降频，视频编码就跟不上了。开会时建议接上电源，或者至少在电源设置里关闭"省电模式"。
强烈建议顺便看一眼系统时间
这个是加分项：如果你的系统时间偏差比较大（比如差了几分钟），可能会影响加密握手的建立。偶尔会遇到"能连上但会议软件提示连接失败"的情况，原因就在这。会前顺手看一眼系统时间是否自动同步，没坏处。
设置四：让会议流量在设备内优先通行
如果你经常同时做几件事——比如开会时还想刷网页、看资料——那这个设置能帮你把"会议流量"和"其他流量"分开。虽然不会让会议本身变快，但能避免其他流量抢占资源导致会议抖动。
把会议应用加入"优先通道"或"白名单"
让会议流量在本地获得更高的转发优先级在 QuickQ 的"智能分流"设置里，有一个"应用优先级"或类似的选项。把常用的会议软件加入"优先"一侧，可以让它的流量在客户端内部获得更快的处理顺序。
这项设置的效果不如前几项明显，但在"会议 + 其他应用同时运行"的场景下，能减少会议被抢资源的概率。如果你平时开会时不开别的程序，这项可以跳过。
如果你用的是手机热点
手机热点下的会议是另一个场景。手机作为热点时，自己也可能在跑别的应用消耗流量；同时热点的信号强度直接影响稳定性。如果你要用手机热点开会，建议：把手机放在稳定、信号好的位置；关闭手机上的自动更新和后台同步；条件允许的话，把手机连上充电器——充电时手机网络的稳定性通常更好。
一个小技巧：重要会议前，可以用手机开一次短的测试会议（比如 1 分钟），然后不挂断，切换设备再测一次。两边都顺利，说明网络状况良好。这比临时发现问题要主动得多。
设置五：根据会议类型调整策略
最后一项是针对"不同会议类型"的微调。不是所有会议都对网络要求一样——一对一的语音通话、五个人的头脑风暴、三十人的全员大会，它们对带宽和稳定性的要求差别很大。
按会议规模选择带宽策略
小型会议重稳定，大型会议重带宽如果你用的是 QuickQ 的订阅服务，不同套餐在带宽和优先级上没有区别，全部走同样的通道。但节点的选择策略可以按会议规模调整：
| 会议类型 | 推荐节点 | 原因 |
|---|---|---|
| 一对一语音 | 低负载节点，延迟容忍度高 | 带宽需求小，稳定性是第一位，可以选稍远但更空的节点 |
| 小型视频会议（3～8 人） | 延迟 + 负载均衡的节点 | 每个人都在双向传输，整体稳定性优先 |
| 大型会议（10 人以上） | 高带宽、出口质量好的节点 | 上行数据量增加，出口带宽决定整体流畅度 |
| 屏幕共享 + 视频 | 带宽优先、延迟可稍放宽 | 屏幕共享本质上是持续的高码率视频流 |
如果会议中需要共享屏幕并且同时开视频（比如做演示时想让对方看到你的脸和你的屏幕），那是整个会议场景里最吃网络的一种。这种时候优先选高带宽的节点，宁可延迟高一点，也不要因为带宽不够导致画面糊掉。
关于"共享屏幕时的画质"
如果共享屏幕时对方反映"看不清"，可以试试降低共享分辨率——大多数会议软件支持在共享时选择"优化文字"或"优化视频"。前者降低帧率、提升清晰度，适合展示 PPT 和代码；后者相反，适合放视频。这个调整和网络无关，但效果往往立竿见影。
会前 3 分钟速查：一张可以照着做的表
如果会议马上要开始了，没时间仔细看前面的内容，可以直接对着下面这张表操作。每一项都给出了明确的判断标准和操作动作。
看客户端状态显示"已连接"；进入分流设置确认会议应用被包含在加速范围内。不确定就临时关闭分流。
必做如果之前有固定好用的节点，直接用它；如果没有，打开节点列表按负载排序，挑一个靠前的。别只看延迟。
必做暂停网盘同步、系统更新、后台下载；关闭不用的浏览器标签页；确认笔记本接上电源。
必做确认选用的是正确的麦克风和摄像头；如果网络不稳，可以在会议软件里选择"降低视频质量"或"关闭高清视频"来换取稳定性。
按需如果会议很重要，提前一分钟开个测试房间，确认音视频都正常。早发现早处理，别等会议开始才发现问题。
推荐会议优化时的几个常见误区
除了做好上面这些设置，也要避免几个常见的错误做法。
小结：会议不卡的核心是"减少变量"
回到最开始那个问题——为什么带宽充足，会议还是会卡？因为会议需要的不是"带宽大"，而是"波动小"。而波动往往来自那些没被注意到的细节：分流没覆盖、节点负载高、后台在下载、CPU 在忙别的事、系统时间偏差了——每一个都像是一粒沙子，单独看没关系，几粒凑在一起，会议就开始抖。
上面这五个设置，本质上都是在减少变量：把不相关的东西关掉，把会议流量集中到一条稳定的线路上，让音视频处理有足够的算力支撑。变量少了，波动自然就小了。
可以带走的四句话
- 会议要稳，不要快。带宽大不等于会议顺，抖动和丢包才是真正的敌人。
- 先确认会议流量真的走了加速通道。开了 QuickQ 不等于会议一定被加速，分流规则要检查。
- 选节点看负载，不只看延迟。负载低的节点，稳定性通常更好。
- 把设备的资源留够。关掉下载、关掉多余的标签页、接上电源——一半的会议卡顿来自本地。
如果看完这篇还想了解"为什么会议对抖动特别敏感"，可以看 延迟、抖动、丢包 那篇，那篇用快递配送的比喻把三个指标的关系讲得很透。如果会议中出现具体的连接问题，可以看 连接排查 那篇，里面有一套可以按顺序走的排查流程。
