GitHub 連線逾時打不開？v2rayN 設定排錯完整指南

先確認問題到底出在哪裡

在 v2rayN 裡打不開 GitHub，常見表現不只有一種：瀏覽器一直轉圈、顯示連線逾時、只能開啟首頁卻打不開儲存庫、圖片和腳本載入不完整，或是瀏覽器可以使用，但執行 git clone、git pull 時卻顯示無法連線。這些現象看起來都像「GitHub 被擋住」，實際上可能分別來自代理模式、分流規則、DNS 解析、節點品質或 Git 沒有使用代理。

排查前先把問題拆成三段：第一段是電腦能否解析 GitHub 網域；第二段是 v2rayN 是否真的接管了瀏覽器流量；第三段是 Git 等命令列工具是否獨立設定了代理。不要一看到逾時就立刻重裝 v2rayN 或反覆更新訂閱，先用最小範圍的測試找出哪一段失敗，後面的修正才不會互相干擾。

建議先用瀏覽器開啟 GitHub 首頁，再嘗試一個具體的儲存庫頁面，以及帶有圖片、Release 或 Raw 內容的頁面。如果只有某個儲存庫失敗，不一定是本機代理問題，也可能是該頁面的資源網域、登入狀態或儲存庫本身暫時異常。若所有 GitHub 頁面都逾時，再進入用戶端與節點排查。

先用系統代理建立可驗證基線

第一次排錯時，建議先使用 v2rayN 的系統代理模式，不要同時開啟 TUN、其他 VPN、瀏覽器代理外掛或第二個代理程式。系統代理的好處是範圍清楚，瀏覽器與許多桌面應用會讀取作業系統的代理設定，出現問題時比較容易判斷到底是節點無效，還是特定程式沒有遵循代理。

在 v2rayN 中先確認已選取一個節點，再開啟系統代理。Windows 使用者可以到系統的網路代理設定中查看代理是否已被寫入；如果代理開關顯示關閉，即使 v2rayN 介面看起來已連線，瀏覽器仍可能直接連線。此時先關閉瀏覽器後重新開啟，再測試 GitHub，避免瀏覽器繼續使用舊的連線狀態。

代理模式通常還會搭配全域、規則或直連等路由選項。排錯時可以暫時使用較容易觀察結果的全域代理，確認 GitHub 能否開啟。若全域代理可以連線、規則模式卻逾時，問題多半落在分流規則或 DNS 判斷，而不是節點完全失效。測試完成後，再切回規則模式並逐步調整，不要長期為了方便而忽略原本的分流需求。

如果全域模式下瀏覽器仍然無法開啟 GitHub，先不要急著研究路由規則。這時應該測試另一個節點，並查看 v2rayN 的連線日誌是否有請求記錄。完全沒有請求，通常表示瀏覽器沒有走到代理；有請求但持續逾時，則比較像節點、出口網路或傳輸參數問題。

分流規則與 DNS 是最常見的盲點

規則模式下，GitHub 相關流量可能被判定為直連。若目前網路無法直接存取 GitHub，瀏覽器就會等待到逾時；此時 v2rayN 可能仍顯示節點正常，因為其他網站的請求確實有經過代理。這也是「YouTube 或其他網站能開，GitHub 卻打不開」時最值得優先檢查的方向。

先查看 v2rayN 的路由或分流設定，確認 GitHub 網域沒有被放進直連清單。GitHub 不只使用一個主網域，實際頁面還可能載入 github.com、www.github.com、api.github.com、raw.githubusercontent.com、objects.githubusercontent.com、githubusercontent.com 等相關網域。儲存庫頁面、Raw 檔案、Release 資產與 API 請求未必走同一個主機，因此只處理一個網域，可能出現首頁能開、下載仍失敗的情況。

DNS 也可能讓分流判斷失準。若系統先用本地 DNS 解析，再依解析結果套用規則，GitHub 相關網域可能被錯誤判定為直連，或解析結果本身就不穩定。可以在 v2rayN 的 DNS 選項中確認目前使用的解析方式，避免同時受到瀏覽器安全 DNS、系統 DNS、路由器 DNS 和代理內置 DNS 多重接管。

排查 DNS 時不要一次改動很多選項。先記下原本設定，再只調整 DNS 模式或相關解析伺服器，重新啟動 v2rayN 後測試。Windows 也可以清除本機 DNS 快取，使用 ipconfig /flushdns，但清快取只能處理本機暫存結果，不能修復失效節點或錯誤的分流規則。若改完 DNS 後只有部分網域恢復，仍要繼續檢查 GitHub 的附屬資源網域。

判斷是節點問題還是本機設定問題

節點狀態正常，不代表節點一定能穩定存取 GitHub。延遲測試通常只能反映測試請求能否抵達伺服器，不能完整代表 GitHub 網頁、API、Raw 內容和大型 Release 檔案的實際體驗。某些節點可能首頁勉強能開，遇到長連線、TLS、圖片資源或大檔案下載就頻繁逾時。

最有效的方式是做對照測試。先在目前節點下使用全域代理開啟 GitHub，再換一個不同地區或不同協定的節點測試。如果只有某一個節點失敗，優先淘汰該節點，不要為它修改整套 DNS 和路由設定。如果多個節點都失敗，但其他代理工具或另一個網路可以開啟，才需要回頭檢查 v2rayN 的核心版本、路由設定與本機衝突。

也可以暫時切換手機熱點進行比較。原本 Wi-Fi 逾時、手機熱點正常，表示問題可能發生在路由器、公司或校園網路的出口限制；兩種網路都失敗，才更值得懷疑節點或用戶端設定。測試時要保持其他條件相同，例如同一個節點、同一個瀏覽器和同一種代理模式，否則結果很難比較。

如果 v2rayN 日誌出現 TLS 握手失敗、連線被重設或上游逾時，可以先確認系統日期、時間和時區是否正確。時間偏差可能造成憑證驗證異常。接著確認沒有同時啟用其他 VPN、網路加速器、公司安全軟體或瀏覽器代理擴充功能。多個工具同時修改代理或 DNS，是最容易造成「有時能開、有時逾時」的原因之一。

瀏覽器能開，但 Git 指令仍然失敗

瀏覽器能開 GitHub，只能證明瀏覽器流量已經成功使用代理，不能代表 Git 自動沿用同一設定。Git 通常是獨立的命令列工具，它可能讀取自己的全域設定、環境變數，或根本沒有設定代理。因此遇到 git clone 逾時時，先把它視為另一個問題處理。

可以先檢查 Git 是否存在舊代理設定，使用 git config --global --get http.proxy 和 git config --global --get https.proxy 查看。如果輸出的是已經停用的本機埠號、舊電腦位址或不存在的代理服務，Git 就會直接連到錯誤位置。清除失效設定可使用 git config --global --unset http.proxy 與 git config --global --unset https.proxy，然後再測試。

若你希望 Git 經由 v2rayN 的本機代理連線，應依 v2rayN 實際顯示的本機位址和埠號設定，而不是照抄別人的數字。HTTP 代理和 SOCKS 代理的格式也不同，設定前先確認 v2rayN 開啟的是哪一種入站服務。埠號設定錯誤時，瀏覽器可能完全正常，但 Git 會立即顯示連線被拒絕或等待逾時。

還要注意 Git 使用的位址類型。透過 HTTPS 下載時，Git 主要使用 https.proxy；若儲存庫遠端位址是 SSH 格式，例如 [email protected]:owner/repo.git，它不會直接套用一般的 HTTPS 代理設定。新手排錯時可以先把遠端位址改成 HTTPS 形式，確認基本下載流程正常，再研究 SSH 的獨立代理或替代連線方案。

測試 Git 時，先從小型且公開的儲存庫開始，執行一次 git ls-remote 或查看遠端資訊，比直接下載大型專案更容易判斷。若命令列仍失敗，可以檢查 Git 輸出的錯誤是 DNS、連線拒絕、TLS 還是逾時。錯誤類型不同，對應的排查方向也不同，不要只把所有訊息都歸類成「GitHub 被封鎖」。

一套由簡到難的排查順序

  1. 確認 v2rayN 已選取可用節點，並記下目前使用的代理埠號。
  2. 暫時關閉其他 VPN、代理軟體與瀏覽器代理外掛，避免多重接管。
  3. 先使用系統代理和全域模式，重新啟動瀏覽器後測試 GitHub。
  4. 若仍逾時，換一個節點，並用手機熱點做一次對照測試。
  5. 若全域可用、規則不可用，檢查 GitHub 相關網域是否被錯誤分到直連。
  6. 檢查 DNS、系統時間，必要時清除 DNS 快取後重新測試。
  7. 瀏覽器恢復正常後，再單獨檢查 Git 的全域代理設定和遠端位址。
  8. 最後才考慮更新 v2rayN 或核心，並在更新前備份訂閱與自訂設定。

每完成一個步驟，就記錄測試結果，例如「全域模式可用、規則模式失敗」或「瀏覽器可用、Git 失敗」。這些簡短紀錄能幫你快速縮小範圍，也方便向節點服務提供者回報。不要在同一次測試裡同時更換節點、DNS、核心和路由，否則即使恢復正常，也不知道真正有效的是哪個改動。

常見問題

為什麼 GitHub 首頁能開，Raw 或 Release 卻打不開？ 這通常是附屬資源網域沒有套用相同代理規則，或目前節點對大檔案與長連線不穩定。先確認相關網域沒有被分到直連，再換節點測試。

開啟 TUN 就一定能解決 GitHub 逾時嗎？ 不一定。TUN 主要是擴大流量接管範圍，不能修復失效節點、錯誤 DNS 或 Git 自己的代理設定。如果瀏覽器在系統代理下已經能開啟 GitHub，就沒有必要為了這個問題直接增加 TUN 的複雜度。

要不要把 GitHub 永久設定成全域代理？ 如果你經常使用 GitHub、Git、API 和 Release 下載，讓相關網域穩定走代理通常比較省事；但具體規則仍應依你的網路環境和使用需求調整。先用全域模式驗證故障來源，再建立精確分流會更可靠。

更新 v2rayN 後還是逾時，下一步怎麼做？ 回到節點與網路對照測試，確認是否只有單一節點失敗；接著檢查 DNS、時間、分流和 Git 設定。更新用戶端只能排除版本相容性問題，不能讓已失效的訂閱或節點重新恢復。若所有節點、所有網路都失敗，再整理日誌與錯誤訊息向服務提供者確認。

總結來說，GitHub 在 v2rayN 中連線逾時時，最穩妥的順序是先用系統代理和全域模式建立基線，再分別檢查節點、分流、DNS 與 Git 設定。瀏覽器和命令列是兩條不同的流量路徑，必須分開驗證。只要每次只改一個變數，通常很快就能判斷是本機設定、網路出口，還是節點品質造成問題。工具與節點請從可信來源取得，並依照所在地法律與服務條款使用。