F100-C-G5-1L

检查下网络情况，

飞书文字聊天、消息走 TCP 443 HTTPS（可靠长连接），而会议音视频画面 / 语音完全依靠 UDP 50000~55000 动态高端口传输。
H3C F100-C-G5 默认全局 UDP 空闲会话老化仅 30 秒：
开会时画面静默、没人说话的间隙，UDP 流短暂停顿，防火墙 30 秒就把 UDP 会话表删掉；后续飞书继续发送视频 UDP 包时，防火墙没有对应回程会话，直接丢弃视频流量 → 会议 1 分钟左右断连，飞书弹窗提示「防火墙 / 代理拦截连接」。
你防火墙两年没改动，但近 2 个月飞书客户端持续升级，新版会议静默场景更多、UDP 静默时间变长，刚好触发防火墙 UDP 会话超时断流；
只用 MAC 白名单放行，没有单独给飞书会议 UDP 延长会话老化、没完整放行飞书媒体网段，最终只断会议、文字正常。
次要诱因（叠加导致恶化）
原先白名单只放行了飞书域名 / 443 端口，没有放行飞书媒体服务器网段 + UDP 50000-55000 端口，早期飞书版本媒体复用 443，新版拆分独立 UDP 媒体端口；
防火墙开启了 DPI 应用识别、入侵防御，新版飞书会议特征被防火墙误识别为异常流量间歇性丢包；
MAC 白名单模式下，如果员工电脑网卡变更、WiFi 漫游更换 MAC，终端命中默认拒绝策略，视频流量断续被拦截。
分步修复方案（无需改动原有 MAC 白名单，业务在线配置）
步骤 1：给飞书安全策略延长 UDP 会话老化（核心根治，必配）
进入防火墙命令行，找到你放行飞书的 MAC 白名单规则，单独加长这条规则的会话超时，让会议 UDP 不会空闲被删掉：
h3c
system-view
security-policy ip
# 替换成你自己飞书白名单规则名称
rule name Feishu_Mac_Allow
# TCP长连接老化1天，UDP会话老化2小时（彻底解决静默断流）
session aging-time tcp-est 86400
session aging-time udp-ready 7200
# 保存配置
save
步骤 2：完整补全飞书会议放行规则（适配新版飞书媒体架构）
原有仅 MAC 放行 443 已经不够，新增放行飞书媒体网段 + UDP 媒体端口，叠加在现有白名单内：
1）创建飞书媒体地址对象
h3c
object ip Feishu_Media
subnet 3.7.25.128 255.255.255.128
subnet 3.101.32.0 255.255.255.128
subnet 3.235.69.128 255.255.255.128
subnet 18.141.149.128 255.255.255.128
subnet 47.113.76.128 255.255.255.128
# 飞书会议UDP媒体端口段
object service Feishu_Media_UDP
service udp destination-port range 50000 55000
service tcp destination-port range 50000 50500
2）在原有 MAC 白名单规则内追加放行媒体流量
h3c
security-policy ip
rule name Feishu_Mac_Allow
permit destination ip Feishu_Media service Feishu_Media_UDP
步骤 3：全局优化防火墙 UDP 默认老化时间（兜底优化）
如果内网大量人员开会，全局调高 UDP 空闲超时，避免所有 UDP 视频业务被误删：
h3c
system-view
# UDP就绪状态空闲超时改为120秒（默认30s）
session aging-time state udp-ready 120
步骤 4：关闭容易误拦截飞书会议的安全功能（解决间歇性丢包）
新版飞书会议加密 UDP 流容易被 IPS、应用检测误拦截：
h3c
system-view
# 在飞书放行策略里关闭深度安全检测
security-policy ip
rule name Feishu_Mac_Allow
undo application filter enable
undo ips apply policy
步骤 5：校验 MAC 白名单有效性（防止员工 MAC 变动导致断网）
查看当前飞书规则命中次数，确认员工终端流量正常匹配白名单：
h3c
display security-policy rule name Feishu_Mac_Allow hit-count
员工更换网卡、连手机 WiFi 时 MAC 改变，会落到防火墙默认拒绝策略，视频直接断开，及时更新 MAC 对象组即可。
步骤 6：开启 ALG 辅助飞书 NAT 穿越（NAT 组网必开）
F100 做出口 NAT 时，开启 STUN / 媒体 ALG，保障会议 P2P 媒体流正常回程：
h3c
system-view
firewall alg stun enable
firewall alg rtcp enable
验证排查命令（配置完成后检测是否生效）
开会期间查看飞书 UDP 会话是否稳定存在，不会 30 秒消失：
h3c
display session table destination-port range 50000 55000 protocol udp
查看防火墙是否存在丢包（IPS / 安全策略丢弃会议流量）：
h3c
display packet-drop reason ips
display packet-drop reason security-policy
查看飞书策略命中计数持续上涨，无 deny 丢弃。
补充临时测试方案（快速定位是不是会话老化问题）
任选一台故障电脑，连上内网 WiFi 开会：
防火墙临时把 UDP 全局老化改成 300 秒，开会测试；
若会议不再断开，100% 确认是 UDP 会话超时导致，完成上面步骤 1 即可彻底解决。
为什么两年正常、近 2 个月才故障？
旧版飞书会议媒体流复用 443 TCP 端口，TCP 老化 1 小时不会断；
近 2 个月飞书迭代更新，会议音视频改用独立 UDP 高端口传输，静默场景变多，撞上防火墙默认 30 秒 UDP 超时机制；
防火墙配置从未改动，规则逻辑没变，但上游飞书应用协议发生变化，最终出现「文字正常、会议断开」的差异化故障。
配置完成后，飞书会议静默挂机、长时间开会都不会被防火墙踢断。

根据你的描述，防火墙策略已稳定运行两年，近期飞书会议才出现问题，这很可能与飞书服务端的策略或IP地址变更有关。防火墙配置虽然没变，但其依赖的“飞书白名单”可能已经过时了。

📝 排查步骤

建议按以下顺序排查，定位并解决问题：

第1步：确认安全策略是否匹配（首选）

1. 查看策略命中数：在防火墙上执行命令，查看针对飞书的白名单策略在过去一段时间内的命中次数是否有增长。

   text

   display security-policy rule name <飞书白名单策略名>

2. 检查丢包情况：检查全局丢包统计，看是否存在因安全策略或会话限制而丢弃的数据包。

   text

   display packet-drop interface any

第2步：排查视频会议长连接（核心）

视频会议是长连接，需要媒体流持续传输。如果防火墙的会话老化时间太短，就会在会议进行中切断连接。

• 查看会话状态：在会议进行中执行命令，查看相关会话是否异常。

  text

  display session table destination-port <飞书会议端口>

• 延长会话老化时间：如果会话提前结束，可以在安全策略下为飞书规则配置更长的老化时间。

  text

  security-policy ip rule name <飞书白名单策略名> session aging-time 86400

第3步：更新飞书IP地址与域名白名单（最关键）

飞书的媒体服务IP地址会动态调整。“其余功能正常，唯独视频会议不行”，很可能就是因为视频会议专用的新IP或端口不在你的白名单中。

你需要检查并更新防火墙白名单，确保放行以下资源：

• 信令服务域名：放行 *.***.***、*.***.***、*.***.*** 等域名的 TLS 443 端口。

• 媒体服务IP及端口：放行以下IP段的 UDP/TCP 50000-55000 端口，以及 TCP/UDP 80、443 端口。

  • 39.105.254.0/24

  • 39.105.247.0/25

  • 47.113.76.128/25

  • 47.113.77.0/24

  • 47.113.78.0/24

  • 101.133.204.0/24

  • 120.201.5.0/25

  • 123.184.46.0/25

  • 61.189.2.0/25

• 其他可能需要的IP：还包括 39.102.180.0/24, 120.25.40.0/24, 8.132.46.0/24 等。

飞书的IP和域名会持续更新，建议关注飞书官方的防火墙变更通知以获取最新信息。

第4步：检查MAC地址绑定

既然策略是基于MAC地址的，请确认你绑定的终端MAC地址没有发生变化，例如：

• 设备更换了有线/无线网卡。

• 终端开启了MAC地址随机化功能。
  可以通过以下命令检查ARP表进行核对：

第5步：检查应用层检测（ALG/ASPF）

防火墙的ALG（应用层网关）或ASPF（应用层安全防护）功能可能会错误地干预视频流。

• 开启相关ALG：如果之前未开启，可以尝试开启SIP和H.323协议的ALG，这有助于防火墙正确处理视频协议的动态端口协商。

  text

  alg sip enable alg h323 enable

• 临时关闭测试：可以在非业务高峰期，尝试临时关闭飞书策略上的深度检测（如IPS、AV）或应用识别功能，观察问题是否消失。

第6步：检查防火墙资源与抓包分析

• 检查资源：查看防火墙的CPU、内存、会话数是否过载。

  text

  display cpu-usage display memory-usage display session statistics

• 抓包分析：在防火墙内外网口进行抓包。如果在断连时，外网侧先停止收到数据，问题可能在飞书服务器或运营商；如果是内网侧先断，则问题更可能出在防火墙或内网。