摘要：“网络明明测速千兆，实际传输只有几MB？”“ping防火墙延迟1ms，过防火墙后丢包率30%！”“业务高峰期，VPN用户集体掉线……”
号主：老杨丨11年资深网络工程师，更多网工提升干货，
“网络明明测速千兆，实际传输只有几MB？”
“ping防火墙延迟1ms，过防火墙后丢包率30%！”
“业务高峰期，VPN用户集体掉线……”
在企业网络中，防火墙、UTM、下一代防火墙等安全设备本应是“守护者”，却常常成为网络性能的瓶颈和丢包的“重灾区”。
为什么一个“安全设备”反而导致网络不稳定？
是配置错了？策略太严？还是设备不行？
想必大家都碰到过这样的问题，今天就带大家深入剖析防火墙丢包的三大核心原因。
✅ 内网测速正常，过防火墙后速度骤降
✅ ping 防火墙自身延迟低，但 ping 外网延迟高、丢包
✅ 业务高峰期（如视频会议、大文件传输）连接失败或中断
✅ 防火墙CPU或内存利用率持续 >80%
✅ 日志中频繁出现 session table full、policy deny 等告警
关键判断：
如果绕过防火墙直连，网络恢复正常 → 问题极可能出在防火墙
防火墙是状态检测设备，它会为每一个网络连接（如TCP会话、UDP流）创建一条会话表项，记录：
源IP、源端口
目的IP、目的端口
协议类型
连接状态（如ESTABLISHED）
老化时间
只有匹配会话表的流量才被允许通过。
display firewall session table verbose | count# 当前会话数：120,000
# 查看最大容量：
display firewall statistic system-capability
# Session Table: Max 100,000 → 已超限！
✅ 解决方案：
优化老化时间：[USG] firewall session aging-time tcp 600 # 从1800秒改为600秒[USG] firewall session aging-time udp 60 # UDP从120秒改为60秒
限制单用户最大会话数：[USG] firewall session link-limit source-ip 192.168.1.0 24 maximum 500
升级设备：选择会话数规格更高的型号三、原因二
安全策略（Policy）匹配效率低
防火墙对每个数据包都要遍历安全策略列表，直到找到匹配项。
如果策略数量多、顺序乱、范围大，那么这个匹配过程将消耗大量CPU。
[USG] policy interzone trust untrust outbound
[USG-policy-interzone-trust-untrust-outbound] rule 1 deny ip source 192.168.1.100 0.0.0.0 # 拦1个IP
[USG-policy-interzone-trust-untrust-outbound] rule 2 permit ip source any destination any # 放行所有
问题：拒绝规则放前面，但绝大多数流量是“允许”的，
每个包都要先匹配rule 1，再匹配rule 2 → 效率低下
策略排序：高频放前面，精确放前面rule 1 permit tcp source 192.168.1.0 0.0.0.255 destination 8.8.8.8 0.0.0.0 destination-port eq 53rule 2 deny ip source 192.168.1.100 0.0.0.0
**避免 any any**，明确源/目的IP和端口按业务分区域，减少跨区域策略数量关闭不必要的深度检测功能四、原因三
硬件性能瓶颈
即使配置完美，设备硬件能力不足仍是硬伤。
关键性能指标：display cpu-usage
display memory-usage
display firewall statistics system
# 查看安全功能性能损耗
display firewall performance
✅ 解决方案：
它不像交换机那样“傻瓜转发”，而是对每个包进行深度分析和状态跟踪，天然存在性能开销。
最后建议：
让防火墙真正成为“安全屏障”，而不是“网络堵点”。
来源：网络工程师俱乐部一点号
