公司新开了三个外地办事处，IT同事连夜把总部服务器的业务系统做了镜像，配上VPN隧道，信心满满地通知大家“广域网已打通”。结果第二天财务报账卡顿、CRM查客户资料要等半分钟——这事儿我见过太多次了。
带宽不是越宽越好，得看实际用法
很多人一想到扩展广域网，第一反应就是“加带宽”。但真这么干，可能白花钱。比如某制造企业给分厂拉了100M专线，结果每天只传几份PDF图纸和少量MES状态包，平均利用率不到3%。反倒是视频会议偶尔卡顿，因为没做QoS策略，突发流量挤占了关键业务通道。建议先抓一周流量，用Wireshark或PRTG看清楚：哪些端口在跑、协议类型（TCP/UDP）、峰值时间、是否加密（TLS握手开销不小）。
延迟比丢包更伤应用
本地局域网ping是0.2ms，跨省走运营商线路动辄35ms以上。对HTTP网页影响不大，但对SQL Server的远程查询、Oracle RAC心跳、甚至某些Java应用的JDBC连接池超时设置（默认30秒），就容易触发重连风暴。曾帮一家连锁药店调优，把数据库连接串里的connect timeout=15改成connect timeout=45，故障率直接降了七成。
别让加密拖垮设备性能
启用了IPSec或SSL VPN后，发现防火墙CPU长期90%+？常见陷阱是：选了AES-256-GCM这种强算法，但旧型号USG或ASA设备压根不支持硬件加速。实测过一台Cisco ASA5506-X，在启用全流量SSL解密时吞吐量掉到标称值的1/4。解决方案很实在：非敏感业务改用IPSec transport mode（省去隧道封装开销），或者把加密卸载到专用SSL加速卡上。
DNS和时间同步，最容易被忽略的两个点
新节点上线后，服务器日志里一堆certificate verify failed报错？八成是NTP没对准——证书校验依赖系统时间，跨时区又没配NTP服务器，差个几分钟就拒连。还有DNS，别直接填运营商的114.114.114.114，跨省解析慢且不稳定。我们习惯在分支路由器上配一条静态DNS转发规则：
ip dns server
ip dns view default
ip dns view-group default
dns forwarder 10.1.1.10 # 指向总部内网DNS主服务器测试不能只看“通不通”，要看“稳不稳”
上线前别只ping一下就收工。真实场景下，拿业务系统本身当探针：写个Python脚本模拟用户登录→查库存→提交订单，循环跑2小时，监控响应时间P95是否突增、有无连接重置（RST包）。某次就靠这招提前发现了MPLS链路隐性丢包——ping显示0%丢包，但TCP重传率高达8%，原来是中间某台老旧BRAS设备队列溢出。