笔记软件代理冲突排查实录：为什么一打开思源笔记全网就断连？

最近我的网络环境有点“玄学”，时不时就会彻底断网。浏览器打不开网页，终端 ping 不通外网，就连平时稳定的即时通讯软件也开始掉线。最离谱的是，这种断网没有任何规律，直到我反复测试发现了一个惊人的规律：只要一打开思源笔记，几分钟内网络必崩；一关闭它，网络又神奇地恢复了。

既然锁定了“嫌疑人”，那咱们就来一场硬核的故障排查。这不仅仅是为了修好网络，更是搞清楚软件在底层到底干了什么。

任务管理器资源占用正常但网络断开

任务管理器显示资源占用正常，排除了资源抢占问题

遇到这种一开某软件就断网的情况，直觉反应通常是：这软件是不是有毒？或者是不是后台在疯狂上传占满带宽？

但我看了一下任务管理器（活动监视器），思源笔记的 CPU 和内存占用都很正常，网络上传下载流量也是 0kb/s（因为我当时并没有进行同步操作）。这说明不是资源抢占的问题。

既然不是带宽被吃完，那剩下的最大嫌疑就是：代理冲突。

系统代理软件配置界面

复杂的系统代理规则可能导致环状请求或流量被误拦截

现在的网络环境通常比较复杂。为了访问某些服务，我们可能会在系统层面开启代理，或者使用 TUN 模式的代理软件接管全局流量。同时，很多现代化的笔记软件（包括思源）都内置了“资源拦截”或者“外部资源加载”的代理设置。

问题往往就出在这里。

系统代理 vs. 软件内置代理：如果系统已经开启了 HTTP/SOCKS 代理，而思源笔记内部也配置了代理路径（或者它尝试自己去抓取某个外部资源时走了错误的逻辑），可能会导致“环状请求”。也就是说，请求发出去了，又被指派回代理端口，但代理软件因为规则问题拒绝了这个请求，或者形成了死循环，最终导致整个系统的网络栈卡死。
TUN 模式的“误伤”：很多朋友的电脑上跑着 Clash 或 sing-box 之类的代理工具，并开启了 TUN（虚拟网卡）模式。这种模式下，所有的流量都会被强制接管。思源笔记是一个本地应用，它可能并不知道自己处于一个被代理的环境中。当它尝试同步或者请求某些 API 时，如果代理软件的规则没有正确地“直连”或者“绕过”本地环回地址，就可能会把思源发出的合法请求给拦截或搞丢，导致超时。严重情况下，某些底层网络驱动处理不过来，就会引发全网的短暂瘫痪。

既然知道了原理，解决起来就有方向了。如果你也遇到了类似的情况，建议按以下步骤操作：

打开思源笔记的设置，仔细检查“网络”或者“代理”相关的选项。

建议：如果你系统层已经有完善的代理工具（比如 Clash Verge、V2Box 等），请务必将笔记软件内部的代理模式设置为“不使用代理”或“直连”。不要让软件自己在那里瞎折腾规则，交给系统层面的统一网关处理最稳妥。

打开你平时用的代理软件（这里就不具体点名哪个客户端了，大家懂的都懂），查看它的日志（Logs）。

当你断网瞬间，日志里是不是在疯狂刷屏红色的拒绝（Reject）或者超时（Timeout）记录？
看看是不是有关于 Siyuan、127.0.0.1 或者本地端口的频繁请求？
解决方案：在代理软件的规则里，将思源笔记相关的进程，或者本地局域网地址段，设置为“DIRECT”（直连）。这能防止本地流量被错误地发送到远端代理服务器，再绕回来。

有些代理软件为了更精准地分流，会开启“Sniffing”（流量嗅探）或 TLS 握手接管。这对于浏览器很有效，但对于某些自研网络模块的桌面软件来说，简直就是灾难。

如果你的代理软件里有关闭 Sniffing 或者 TLS 相关的选项，可以尝试关闭它们，看看能否解决问题。虽然这可能会牺牲一点点分流精度，但稳定性会提升很多。

这次排查给我上了一课：网络越复杂，故障点越隐蔽。

以前觉得，“全平台代理”省事，一开全搞定。但在实际使用中，应用层（如笔记软件、浏览器、IDE）和 网络层（系统代理、VPN、TUN 虚拟网卡）的配置如果不统一，甚至相互打架，就会出现这种“打开软件就断网”的怪现象。

如果你现在的网络也不稳定，不妨关掉所有代理，一个一个软件排查，或者检查一下是不是某款“老实人”软件正在被你的科学上网工具误伤。希望这篇记录能帮大家省去几个小时的抓狂时间。