個人積分：5分
文章編號：93472621
個人積分：109分
文章編號：93477945
個人積分：1263分
文章編號：93485838
以下是我CODEX的解析 供你參考
127/8 現在已經在上層判定 DIRECT，再增加多少條 DIRECT Rule，都無法避免底層捕捉與回注。
因此它只能保證「正常走到規則判斷時不使用代理」，不能保證：
- 不進 user-mode queue。
- 不發生封包延遲、亂序或回注失敗。
- 不受錯誤 conntrack 影響。
- 完全不碰 localhost 封包。
而且目前 conntrack 可能在 Rule 前就以 src_port 命中舊代理紀錄，這時連 DIRECT Rule 都不會執行。
但不能說整個 Rule 功能沒用。它對外部流量仍有用途，例如：
- 指定某個程式走代理。
- 特定目的地直連。
- 特定 port 阻擋。
- 在多個代理間選擇。
只是目前的 DIRECT 更準確的名稱應該是：
Captured Passthrough（捕捉後原樣回注）
而不是：
True Bypass（完全不攔截）
所以正確架構應該是：
- 127.0.0.0/8、::1：在 WinDivert filter 層直接 bypass。
- TCP 33100、UDP 33200：保留 relay 例外。
- 其他程式／目的地規則：繼續由上層 Rule 決定 DIRECT／PROXY／BLOCK。
- 同時修正 port-only TCP conntrack。
換句話說，上層 Rule 沒辦法修好 localhost 這個問題，必須改底層 filter。
作者確實「有加入」，但加入的是上層自動 DIRECT，不是底層封包排除。
目前狀況：
- 10.0.0.0/8
- 172.16.0.0/12
- 192.168.0.0/16
- IPv6 fc00::/7
- 作用中網卡的 on-link 網段
都會被判定為 DIRECT，但封包仍然：
WinDivert 捕捉
→ user-mode queue
→ conntrack
→ checksum
→ WinDivertSend 回注
所以功能上「不走外部代理」通常成立，但穩定性上仍可能：
- 延遲或掉包。
- 被錯誤 conntrack 覆蓋。
- 既有長連線局部 timeout。
- 虛擬網卡啟動或換 IP 後，on-link cache 沒即時更新。
- ::1 因程式 bug 沒有正確識別。
而且 LAN 判斷在舊 conntrack 之後；若相同 src_port 已有舊代理紀錄，封包可能在抵達 LAN/DIRECT 判斷前就被改送到 relay。
因此比較準確的說法是：
作者加入了「內網自動直連政策」，但沒有實作「內網底層 bypass」。
不代表每條內網連線都必定失敗；低流量、沒有 port collision 時通常正常。但依你目前已經出現短連線與既有 MySQL 長連線 timeout 的證據，這個版本在你的多服務／Docker／大量 localhost 連線環境下，確實不夠穩定。
個人積分：173分
文章編號：93486837
Gpc wrote:
目前測試Rule會吃...(恕刪)
感謝你這麼深入的分析，判斷基本上完全正確，我逐項對照過原始碼確認了。這三個架構性問題我已經全部修好了：
1. 內網/localhost 底層 bypass — 已修 你說得對，舊版是「Captured Passthrough」：127.x/::1 在上層被判 DIRECT 後原樣回注，但封包還是進了 user-mode queue（延遲、排隊、掉包的來源）。現在已改成在 WinDivert filter 層直接排除 127.0.0.0/8 和 ::1，loopback 封包完全不再被捕捉。我用驅動實測過：同一台機器產生 loopback 流量，舊 filter 會攔到、新 filter 是零捕捉。
2. TCP conntrack 的 port-only 問題 — 已修 這點抓得很準。舊版 TCP 條目只用 src_port 當 key，程式異常關閉（沒 FIN/RST）時殘留條目最長會活 1 小時；Windows 又很激進地重用臨時埠——新連線若抽到同一個埠，封包會在抵達 LAN/DIRECT 判斷前就被舊的 PROXY 條目改送進 relay，症狀就是「偶發被轉走」。現已改為完整 key（src_port + family + 原始目的地）：stale 條目對不同目的地必然 miss，封包正常走規則評估；同埠不同目的地也可並存。另外你環境（Docker／多服務／大量 localhost 連線）最容易踩中這個，跟你的 MySQL 長連線 timeout 症狀吻合。
3. on-link cache 不更新 — 已修 正確，原本只在啟動時抓一次網卡網段。現在 cleanup thread 每 10 秒刷新一次，虛擬網卡中途啟動或 DHCP 換 IP 都會被納入。
補充兩點：::1 識別在目前版本其實已正確處理；亂序問題也在上一版修掉了（單一 receiver + per-flow 工作緒）。你的 CODEX 分析裡「正確架構應該是……」那段的建議方向，這次就是照著做的。新版本麻煩你再測一下多服務環境的穩定性，特別是 MySQL 長連線那段，有狀況再回報給我，謝謝！
https://github.com/tokyoxpa3/NetRedirector/releases/
個人積分：0分
文章編號：93494310
FT.JB wrote:
感謝你這麼深入的分析...(恕刪)
樓主您好。
非常感謝您的開發實在是太造福大眾了
我在其他板頁看到你的留言，裡面有這句話。
"兩個5G門號聚合的網速下載東西奇快，平均1Gbps以上"
這句我不太了解，當時你的意思是
兩張SIM卡裝在同一個手機執行 5G Proxy Pro，這樣嗎？
還是我有兩個手機各一個sim卡，合併執行同一個5G Proxy Pro？
又或者兩個手機各一個sim卡各執行一個5G Proxy Pro，pc端負載平橫同時使用兩條網路？
我對這個用法感到十分羨慕及技術的精湛。
個人積分：173分
文章編號：93498960
spysndb wrote:
樓主您好。非常感謝您...(恕刪)
哈囉，感謝捧場！
你猜得很接近了，正確答案是第三種的變形：
我是兩支手機、各插一張 5G SIM，各自開一個 5G Proxy Pro，把每支手機變成一個獨立的 SOCKS5 代理端點。然後在電腦上跑支持同時間主線路和多代理網速聚合的下載器，我剛好開發了一款https://github.com/tokyoxpa3/MultiSocksDownloader，一次掛上這兩個代理位址，讓它把下載流量同時聚合兩條 5G 線路和一條原來家用PPPoE網路的網速。
這樣同時間三條網路的頻寬就能疊加，所以下載大檔案時才會常常看到破 1Gbps 的速度。重點是「多代理同時下載」這件事是在 PC 端完成的，手機端只是單純各當一條代理出口而已。
至於第一個選項（單支手機塞兩張卡）為什麼不行——市面上大多數手機是雙卡雙待（DSDS），兩張卡不會同時跑數據，只能二選一，所以疊不起來。除非你的手機有雙卡雙待雙通（DSDA）而且支援兩張卡同時上網，那種才有機會，但比較少見，我也沒特別去試。
有興趣的話可以自己照這個方向搭看看，兩張不限速吃到飽的門號效果最明顯。祝你玩得愉快！
個人積分：0分
文章編號：93503529
個人積分：173分
文章編號：93504963
b_ wrote:
裝好了 但SOCKS5...(恕刪)
感謝回報！「SOCKS5 回傳空白」通常是「代理有在跑，但流量沒真正從 5G 走出去」，這點過去不容易用肉眼看是哪一段出問題。
新版本 v1.6.1 加了一個「自我檢測」按鈕，直接在 App 裡就能幫你定位，完全不用接電腦或下 adb 指令：
更新到 v1.6.1 → 按「🚀 一鍵開啟 5G 代理」
等狀態變成「✅ 5G Proxy Running」
按「🧪 自我檢測」——它會自動依序測「TCP 連線 → SOCKS5 握手 → CONNECT 隧道 → 資料回流」四步，直接顯示是哪一步 ❌
如果還是失敗，請再按「📋 複製診斷報告」把內容貼給我，我看一眼就能知道確切原因。
幾個可以先自行確認的常見原因：
客戶端 SOCKS5 的 IP 要填 App 上顯示的「Wi-Fi 代理」IP、Port 填 1080；帳密要跟 App 設定一致（兩欄都留空＝不啟用認證）。
手機要有 5G/4G 訊號，且 App 的「5G 行動 IP」要顯示出公網 IP，而不是「尚未鎖定」。
https://github.com/tokyoxpa3/5G-Proxy-Pro/releases
手機自我檢測正常，有甚麼方法可以診斷 NetRedirector
個人積分：47分
文章編號：93508965
個人積分：173分
文章編號：93521523
b_ wrote:
裝好了 但SOCKS5...(恕刪)
手機自我檢測正常，只代表「手機那一段」是通的，不等於「電腦 → 手機」這一段通。NetRedirector 是「電腦端」連到手機 SOCKS5 的客戶端，所以要在 NetRedirector 這邊測。請依序做：
第一步（最重要）：先按「測試所有代理連線 (Ping)」
到「Proxies」分頁，點「測試所有代理連線 (Ping)」。這個按鈕會完整跑一遍 SOCKS5 握手 → CONNECT → 連到 api.ipify.org 取出口 IP，跟實際會走的線路一模一樣，而且失敗會直接告訴你原因：
✅ 顯示「測試成功: MyPhone → 某個 IP」＝代理配置正確，問題在「規則」這一段（跳第三步）。
❌ 顯示「超時」＝電腦連不到手機。通常是 IP/Port 填錯、電腦跟手機不在同一網段，或手機熱點開了「AP 隔離」。
❌ 顯示「連線被拒」＝手機服務沒開。
❌ 顯示「帳號或密碼錯誤」＝兩邊帳密不一致。
第二步：確認 IP 填的是手機 App 顯示的那個
NetRedirector 的代理 IP 要填 5G-Proxy-Pro App 上顯示的「Wi-Fi 代理 IP」、Port 填 1080，帳密跟 App 設定一致（兩欄都空＝不認證）。先確認電腦能 ping 到手機那個 IP，ping 不通就是網段／防火牆／AP 隔離的問題。
第三步：測試通過但程式仍空白 → 看「Monitor」分頁
Monitor 會即時列出被攔截的流量。如果程式開著卻看不到程式的流量，代表規則根本沒命中，流量沒進到 SOCKS5——這才是「回傳空白」最常見的原因。請到「Rules」分頁確認：
進程名稱要對（設定全局*，指定程序名 xxx.exe 或PID）。
動作選「代理 (轉發)」。
代理要選到「[Custom] 你的手機代理」。
補充說明一個已知行為：NetRedirector 的核心層在「上游 SOCKS5 握手失敗」時是靜默斷線，程式端只會看到空白、沒有任何錯誤訊息。所以請不要用「程式有沒有反應」來判斷，用上面那個「測試所有代理連線」按鈕看。
關閉廣告