你關心的，這裏有答案。

客戶端的導入、更新、測速等操作先看存儲目錄中的 guiLogs；核心連接問題先看主界面信息欄。開啓“日誌存到文件”後也可查覈心日誌文件。

記錄系統、客戶端版本、核心版本、錯誤發生時間與最少復現步驟。只截取相關時段，隱藏訂閱令牌、UUID、密碼和私人地址。重複操作前標記時間，便於從舊日誌中區分本次結果。

可以複製多份便攜目錄，分別保存配置和運行。每個實例需要不同的混合監聽端口，並避開 +1、+2、+3、+4、+5、+21 等關聯端口衝突。

多個實例不宜同時接管系統代理或 TUN 默認路由。爲需要的應用手動指定對應實例端口，確認哪個實例負責系統設置。

本網站收錄的 7.25.6 提供 windows-86 ZIP，對應下載頁中的 x86。舊 Wiki FAQ 曾描述需要自行編譯，這是歷史說明；不要因此改用 x64 包。

同時檢查 Windows 版本與核心的 32 位支持。32 位系統無法運行 64 位可執行文件，單獨替換 GUI 架構也不能解決核心架構不匹配。

Windows 下載

當前發佈說明要求 Windows 10 及以上，本頁不把 Win7 列爲受支持系統。舊系統同時涉及 .NET、界面框架和 Go 核心的兼容性，不能僅通過安裝一個運行庫保證正常。

升級系統後使用匹配包是當前下載路徑。需要保留舊環境時，應將舊版客戶端與其對應核心一起評估，不能混用最新核心並期待舊行爲。

先在系統“關於”中確認 ARM64，下載 ARM64 包並完整解壓。GUI 能啓動但核心失敗時，檢查覈心二進制是否也是 ARM64，以及當前協議是否受其支持。

官方 FAQ 中的舊設備兼容討論不能作爲所有 ARM 設備都能運行的保證。記錄 Windows 構建號、處理器和報錯，區分系統仿真、核心架構與配置問題。

Windows 的系統代理界面主要爲使用該設置的應用配置 HTTP 代理。客戶端混合監聽端口本身同時支持 HTTP 和 SOCKS5，不需要系統界面同時顯示兩套才表示有效。

需要 SOCKS5 的應用可以在自己的代理設置中填寫 127.0.0.1 和實際混合端口；HTTPS 請求經 HTTP 代理通常使用 CONNECT 隧道，不表示 HTTPS 內容被降爲明文。

先確認核心正在運行，再查看 guiLogs 中系統代理腳本的錯誤。macOS 代理按網絡服務設置，Wi-Fi 與 Ethernet 可能是不同項；切換網絡後應檢查當前正在使用的服務。

可在“系統設置 → 網絡 → 當前網絡服務 → 詳細信息 → 代理”中核對地址與端口。需要手動配置時，使用 127.0.0.1 和客戶端實際混合端口，並在停止使用後關閉手工開啓的代理項。自定義配置應使用文件中實際監聽的端口。

僅開啓系統熱點不會自動讓其他設備使用本機代理。需要在客戶端允許局域網連接，確認實際 LAN 監聽端口，並讓系統防火牆允許可信局域網設備訪問該端口。

其他設備的代理地址填寫這臺電腦的局域網 IP，而不是 127.0.0.1，端口填寫 LAN 監聽值。保持設備處在可互通的網絡；訪客 Wi-Fi 或 AP 隔離會阻止訪問。只在受控網絡開放，使用後關閉不需要的監聽。

在當前規則集中新增 direct 域名規則，將 geosite:steam@cn 與 domain:steamserver.net 放在代理兜底規則之前；先確認 GEO 數據包含該分類。

這是項目社區提供的分流思路，不保證覆蓋所有地區和 CDN。重啓 Steam 下載後查看真實連接目標與出站；若仍走代理，應根據日誌補充實際下載域名，並區分商店、社區與下載流量。不同核心和規則資源的結果可能不同。

先確認普通網絡能用，再檢查節點是否有效、核心是否啓動、應用是否把請求送到本地端口，最後檢查路由與 DNS。開啓 Debug 只復現一次需要的問題，記錄首個相關錯誤，避免被後續連鎖錯誤干擾。

1. connect refused：確認目標或本地端口有服務監聽。
2. timeout：比較直連、當前節點和其他已知可用節點，縮小問題範圍。
3. certificate / TLS：覈對時間、SNI、證書鏈與固定值。
4. unknown field / unsupported：覈對客戶端與核心版本、完整模板。
5. 核心無請求日誌：先查應用代理設置或 TUN 入口，不要先修改出口規則。

PAC 先由應用運行腳本；DIRECT 的請求繞過核心，因此核心路由和日誌都看不到它。自動代理通常先進入核心，再執行路由分流。

同一網站結果不同，應先確認應用支持並實際使用哪種入口、PAC 是否緩存、例外列表是否匹配，然後再檢查覈心路由。

系統代理模式

先分別檢查節點域名、DNS 服務域名和目標域名。DNS 服務地址本身爲域名時，需要可用的 IP 形式 Bootstrap，避免“先連接代理才能解析代理服務器”的循環。

瀏覽器自己的加密 DNS、系統緩存、Hosts 和 FakeIP 也會影響結果。用默認 DNS 配置建立基線，再逐項開啓自定義選項；不要把 Xray 路由解析與實際出站解析混爲一談。

DNS 基礎與進階

先記錄具體域名、瀏覽器錯誤與發生時間，比較直連和代理結果。檢查該域名是否被直連 / 阻止規則或系統代理例外提前匹配，再看 DNS 返回結果。

網站也可能按出口 IP、地區或賬號狀態限制訪問。用其他已知可用節點對比可以幫助定位，但沒有一條固定規則能解決所有 Bing 問題；不要直接關閉全部證書驗證或刪除所有路由。

記錄完整錯誤，確認客戶端具備運行該工具所需權限，且目標 UWP 應用已安裝。部分精簡系統或 LTSC 環境的應用組件可能不同，應先確認工具能枚舉目標應用。

不要通過關閉整個防火牆來替代迴環授權。如果問題只發生在單個應用，用普通瀏覽器對照測試，確認核心與系統代理本身正常，再處理該應用的沙盒限制。

項目討論中有 TCP 擁塞控制相關的個案，也有端口占用和系統時間問題，不能僅憑“24H2”認定原因。先更新系統補丁，檢查時間、核心日誌和端口，再比較系統代理與 TUN 兩種模式。

可用下方只讀命令查看當前 TCP 設置。只有已定位到特定網絡棧問題時，才針對該項調整並記錄原值；不應把網上整套重置命令作爲默認步驟。

Windows · PowerShell · read-only複製

Get-NetTCPSetting | Select-Object SettingName,CongestionProvider

先關閉 TUN，確認同一節點用普通系統代理可以連接。若普通模式也失敗，先修復節點或核心。只有 TUN 失敗時，檢查權限、虛擬接口創建、默認路由、DNS 與其他 VPN / 虛擬網卡衝突。

按順序嘗試客戶端默認設置、合適協議棧和較小 MTU，每次只改一項。局域網資源不可達時覈對排除 CIDR。ping 可能由本地 ICMP reply 回應，不能獨自證明代理連接成功。

TUN 參數

這通常發生在測試配置啓動階段，不等同於所有節點不可用。查看 Debug 中第一條錯誤，檢查覈心文件架構和執行權限、配置字段是否受支持、本地與測試端口是否佔用。

臨時測試使用基準端口 +21，且批量測試會消耗更多資源。Windows 虛擬化環境還可能保留某些端口範圍。嘗試一個節點和較小批次、換一個不衝突的基準端口，再看錯誤是否變化；不要直接刪除系統保留範圍。

能夠傳輸某種遊戲流量取決於遊戲入口、TCP / UDP、核心和節點支持。許多遊戲不使用系統 HTTP 代理，可能需要應用自身代理設置或 TUN。

代理不保證降低延遲；距離、線路、丟包和鏈式節點都可能增加延遲。先確認遊戲可連，再比較同場景的延遲與穩定性，不能用瀏覽器測速代替遊戲測試。

Windows 可在存儲目錄使用 NotifyIcon1.ico 到 NotifyIcon4.ico 對應系統代理狀態的托盤圖標。先備份已有圖標，再放置有效 ICO 文件並重啓檢查。

規則集配置了自定義 PNG 圖標時，會優先顯示規則圖標，系統代理圖標變化不再直接呈現；因此圖標沒有變化不一定意味着代理模式沒有改變。

系統關機時的退出處理不保證有足夠時間完成。若下次開機沒有運行客戶端，系統卻仍指向本地代理端口，應用可能無法聯網。

重新打開客戶端並選擇清除系統代理，或在系統網絡設置中關閉遺留手動代理 / PAC。之後正常使用時，先清除再退出可以減少殘留。

可以使用這類路徑，但外部核心、腳本、權限或同步軟件可能引入額外限制。啓動失敗時可把完整便攜目錄複製到一個短、可寫的本地路徑進行對照。

在命令行引用帶空格路徑時使用引號。不要只移動主程序而丟失 bin 或配置文件，也不要把權限問題誤當成編碼問題。

客戶端先組合入站、日誌、路由與出站，再應用默認或自定義 DNS，並處理 Hosts 和節點解析。啓用完整模板時，會將生成的代理出站整合到模板，其餘由模板定義的內容可能覆蓋普通設置。

最後啓動核心執行生成結果。因此某個 GUI 設置“看似沒生效”時，應檢查是否啓用了完整模板、自定義配置或顯式 Core 類型，而不是不斷重複修改同一個開關。