前段時間困擾我的一個網絡攔截請求的問題，終于被巧妙地解決了。

我之前開發了一個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并存了，我的代理服務終于又可以正常工作了。

從這次思維改變，我把一個困擾我長達三個的難題解決了，我內心是激動的，這是多年工作之后很少遇到的頓悟時刻。

有時候困難并沒有那么大，只是我們給自己加了太多預設條件和“心墻”，推不倒南墻，但希望在轉角。