服务器晚高峰卡顿、白天正常：按网络与负载排查
白天正常、晚上卡顿，访问路径拥塞只是排查方向之一；同时增加的业务、备份和定时任务也可能造成相似现象。先在正常与卡顿时段，比较同一设备、同一服务器和同一项操作，再决定需要处理哪一层。
先分清“卡”在哪里
- 只有远程桌面画面迟缓：记录输入、画面与命令响应是否都变慢，比较同实例上的其他业务。
- 只有网页或应用慢：区分连接不上、等待响应和下载慢，查看应用日志、数据库及请求量。
- SSH、远程桌面、网站等同时变差：同时采集访问路径与服务器资源，不跳过其中一项。
记下异常开始、结束时间和时区，例如“北京时间20:30—22:00”。白天正常不能排除晚上才触发的负载或定时任务。
白天和卡顿时，各保存一组相同测试
固定客户端、目标IP、实际端口、程序和测试次数。Windows本地命令提示符或PowerShell执行，替换文档示例IP：
ping -n 30 203.0.113.10
tracert -d 203.0.113.10macOS／Linux在本地终端用ping -c 30 实际IP；逐跳统计按MTR文档操作。Ping记录这次ICMP往返时间和应答丢失，tracert提供路径线索；某个中间跳的星号、高延迟或公共DNS探测结果，不能单独判定当前访问路径正常或故障。
再检查实际业务端口。Windows本地PowerShell下例以3389为示例，必须替换为实际配置：
Test-NetConnection -ComputerName 203.0.113.10 -Port 3389 -InformationLevel Detailed记录RemoteAddress、RemotePort和TcpTestSucceeded。True只说明这次TCP连接建立成功，不能证明画面流畅、应用响应或UDP业务正常；False时需同时检查服务、规则和来源路径。macOS／Linux端口命令见端口测试文档。
域名经CDN或代理时，注明测试的是接入节点还是服务器IP。白天与晚上更换了目标或端口，就不能直接作为同条件对照。
在卡顿当时检查本地网络与实例资源
- 本地：记录正在进行的下载或同步，条件允许时暂停后复测；再用有线替代Wi-Fi或切换手机热点。每次只改变一个条件，记录同一业务是否改善。
- 服务器：Windows查看任务管理器／资源监视器；Linux按资源排查文档采样。保存CPU、可用内存、磁盘等待与吞吐、网卡收发和业务请求量。
- 任务：核对备份、日志归档、更新、扫描、批处理等的开始结束时间，以及是否与卡顿重合。先留记录，不直接停用备份或安全更新。
网络变化与资源压力可能同时发生，不因“晚高峰”就省略资源检查，也不先重启、清缓存或结束未知进程而丢失现场。
按对照结果决定下一步
| 对照结果 | 处理方向 |
|---|---|
| 有线或暂停本地下载后改善 | 检查本地无线、路由器或出口占用，并复测原业务；一次改善还不能锁定责任节点。 |
| 网络采样变化不大，业务请求或资源等待上升 | 定位应用、数据库和定时任务，确认影响后安排优化或错峰，再复查同一指标。 |
| 资源无明显变化，特定来源或运营商在晚间异常 | 提供该来源白天、晚间和其他网络的对照，继续核查路径。单条路由不能独立定责。 |
| 多个来源在同一时段失败 | 结合服务日志、共同路径和平台相关记录进一步核查。 |
| 只有某个测速对端慢，真实业务正常 | 只说明该对端和路径的情况，不扩大为全网异常。 |
确有证据指向现有路径不适合实际用户时，先测试候选地区或线路在相同运营商、相同时段的表现，再评估切换。只有确认受限的是CPU、内存、存储还是带宽，才评估对应资源；升级配置或更换IP不保证解决路径异常。
仍无法定位时，附上这组工单资料
- 产品ID、地区、系统，以及异常日期、起止时间和时区。
- 客户端城市、运营商、有线／Wi-Fi／热点，受影响业务和实际端口。
- 白天与晚间到同一目标的完整Ping、路由和业务测试结果；注明CDN／代理目标。
- 同时间的资源、请求量与任务记录，以及切换网络或调整任务后的结果。
截图和日志隐藏密码、令牌和无关客户信息，不需要通过长期跑满带宽来补证据。