Karing显示运行，浏览器却仍在等待。此时先不要反复切换线路：需要确认的是，哪个进程发起了请求、连接到了哪里，以及请求在哪个阶段停止。Windows资源监视器可以提供一部分当前活动线索，但它不是全部网络行为的完整记录。
先建立一个可重复的观察窗口
保留当前配置，关闭无关的大流量任务，记下应用名称、测试时间和一个你有权访问的目标。通过开始菜单搜索“资源监视器”，或按 Win + R 输入 resmon。进入“网络”选项卡，展开“具有网络活动的进程”“TCP连接”和“侦听端口”。不同Windows版本的中文名称与可见列可能有差别。
- 先让待测应用保持空闲，观察当前记录。
- 只发起一次明确请求，例如重新加载同一个页面。
- 对照请求前后增加的进程活动与TCP记录，记录PID。
不要把进程列表中的每条后台连接都归于这次请求。系统更新、浏览器预连接和其他标签页也会联网。完整判断顺序可结合网络连接状态五层检查。
地址、端口与PID能告诉你什么
PID用于对应这一时刻的进程实例。进程名称相同，也可能存在多个实例；退出重启后PID还会变化。本地地址与本地端口标识本机这一端，远程地址与远程端口标识该TCP连接的另一端。侦听端口表示服务在等待连接，与已经发生的出站连接不同。
| 观察项 | 可以支持的判断 | 不能直接证明 |
|---|---|---|
| 进程与PID | 哪个当前进程出现网络活动 | 这个进程的全部历史请求 |
| 本地 / 远程地址与端口 | 这条连接两端的地址信息 | 最终互联网出口及全部中间路径 |
| 侦听端口 | 服务在本地等待连接 | 目标网站已响应 |
| TCP连接记录 | 当前可见的TCP活动 | TLS或HTTP已成功 |
资源监视器不是抓包工具，不适合回看已经消失的历史连接。若当前界面没有给出清晰的握手状态，就不要仅凭一行记录断言连接已经建立。
应用进程与代理进程可能分工
当应用使用本地代理时，浏览器可能先连向本机回环地址，再由代理进程建立远端连接。在VPN类模式下，可见行为还取决于网络实现。应用进程的远程地址因此不一定就是最终访问的网站地址。
请以设备上实际运行的进程为准，不预设Karing的进程名、默认监听端口或固定服务器地址。把应用PID、代理PID和时间放在一起比较，可以减少误认，但仅靠资源监视器仍不能确认最终出口。UDP与QUIC活动也不一定出现在TCP连接列表中；没有TCP记录，并不意味着程序完全没有网络活动。
把连接记录与错误阶段放在一起
找到连接后，再看应用是否取得实际响应。TCP建立成功之后仍可能在TLS协商或应用请求阶段失败；显示“连接失败”也可能来自应用自身的超时逻辑。遇到重置、拒绝或等待超时，应保留原始错误文字，参阅TCP错误类型与发生阶段。
如果访问成功但体验波动，固定目标、网络和测量时段，再按可比较的测速记录方法观察多次结果。不要用一次连接快照推断所有线路的质量。
怎样保留有用而不过量的记录
一份简短记录应包括：时间、Windows版本、待测应用、实际进程名与PID、当前代理模式、目标类型、现象和错误阶段。需要分享时，将IP地址、内部域名、账号标识与日志令牌脱敏，只保留判断所需片段。
验证结束后关闭不再需要的测试窗口，恢复临时改变的应用条件。能复现的现象和准确时间，通常比一张没有上下文的截图更有帮助。
