前段时间困扰我的一个网络拦截请求的问题，终于被巧妙地解决了。
我之前开发了一个net proxy，专门用于对特殊网络环境的模拟，以此测试一个工作中需要测试的软件。简单来说就是用mitmproxy实现一个网络流量代理服务，对网络请求域名进行拦截功能，只有指定的一些域名可以正常访问，其他域名访问就直接返回403。
本来功能都实现得很好，用起来非常丝滑。但后面因为工作网络有了新的要求，必须用工作的虚拟网络通道（简称SXNN）。
在网络通道连接之后，它直接接管了路由，导致流量绕过本地运行的mitmproxy，我的域名拦截就无效了。
而如果先开启net proxy，则又无法顺利连接SXNN的网络服务。
后面想了很多办法，比如通过修改net proxy项目代码，尝试让流量还是走代理拦截。基本把AI服务都用了个遍，vibe coding了2个月，依然无法解决问题。
而且因为涉及了工作要求，我也不能对SXNN的客户端进行改造，比如把网络改为Split Tunnel模式。也就是让指定域名/IP 走本地网络（从而经过 mitmproxy），其他走SXNN。
而且我用来进行对特殊网络环境的模拟的应用也无法再Docker容器里面进行使用，这里面涉及到了更复杂的构建工作以及测试。
AI甚至建议我在连接SXNN之后，把net proxy设置为上游代理，通过一系列复杂的网络命令来实现。我尝试了一下，并没有让流量走mitmproxy。
我在多次的失败之下也短时间放弃了研究，直到这两天在山中修行，夜间无事打开电脑继续和AI进行探讨。
硬碰硬是走不下去的，涉及到底层网络协议和工作安全性的限制，注定是一个死胡同。我需要调整思路，如果先A后B不行，那么先B再A呢，是否就能走出新的路？
我突然想到，如果我没法在连上SXNN之后让mitmproxy成功拦截网络请求，那为什么不先运行net proxy，让网络流量先走我本地的proxy，然后再去接入SXNN。
我唯一要实现的就是，在net proxy运行的条件下，让SXNN服务能连接上个网络即可。于是通过net proxy的网络请求日志，我发现了7个需要加入白名单的域名，它们是用来连接SXNN网络的中间服务域名。
当我把这7个域名加到白名单后，终于顺利实现了SXNN网络连接和net proxy并存了，我的代理服务终于又可以正常工作了。
从这次思维改变，我把一个困扰我长达三个的难题解决了，我内心是激动的，这是多年工作之后很少遇到的顿悟时刻。
有时候困难并没有那么大，只是我们给自己加了太多预设条件和“心墙”，推不倒南墙，但希望在转角。