先分清楚：GitHub、Docker 與套件管理器卡在哪一層

GitHub clone 卡住、Docker 映像檔拉不下來，或 npm、pip 安裝經常逾時，看起來都像是「網路太慢」，但實際上可能發生在不同環節。GitHub 可能卡在網域解析、TLS 連線、儲存庫內容傳輸或 Git LFS 物件下載；Docker 則通常同時涉及 Registry 網域、認證服務、映像檔 manifest 與分層 blob；npm 和 pip 除了套件索引，還可能在解析相依套件、下載輪子檔或原始碼壓縮包時等待。

因此，單純把整台電腦切換到代理模式，不一定是最好的處理方式。它可能改善某個遠端網域的連線，卻也可能讓內部 Git 伺服器、公司網段、套件快取服務或區域網路設備繞遠路。開發者比較需要的是可控的代理、清楚的分流，以及能在失敗後快速定位問題的測試流程。

90+

可選國家

200+

可選線路

不限

同時在線設備

14 天

退款保障

工作內容 常見連線對象 可能卡住的位置 優先檢查項目
Git clone、fetch、push GitHub 網頁、Git over HTTPS、SSH 解析、握手、儲存庫資料或 LFS 代理是否套用到 Git，並檢查實際錯誤訊息
Docker pull、build Registry、認證服務、映像檔分層 登入、manifest 或 blob 下載 Docker daemon 是否取得代理設定
npm install npm registry、套件 tarball、Git 相依套件 索引解析或個別套件下載 registry 設定與 lockfile 來源
pip install Python Package Index、wheel、原始碼套件 索引、檔案下載或建置依賴 index-url、代理與憑證設定

GitHub：分別處理 HTTPS、SSH 與 Git LFS

GitHub 的 Git 操作主要有 HTTPS 與 SSH 兩種方式。HTTPS 通常會連接儲存庫網域，並依照 Git 的 credential helper 或平台登入流程驗證；SSH 則會使用另一個連線埠與金鑰驗證。兩者使用不同的設定入口，所以瀏覽器能開啟 GitHub，並不代表命令列中的 SSH clone 一定能正常工作。

如果使用 HTTPS，應先確認 Git 是否能讀取目前代理設定。可以使用 Git 的全域設定、單一儲存庫設定或環境變數套用代理，但不建議把包含帳密的完整網址直接寫入設定檔。若代理需要驗證，應優先使用作業系統的憑證管理或安全的環境變數，並在分享診斷輸出前遮蓋使用者名稱、Token 與代理位址中的敏感欄位。

SSH 的排查方式不同。執行 ssh -T [email protected] 時，應觀察是否能完成主機連線與金鑰驗證，而不是隻看 GitHub 網頁是否載入。某些代理用戶端只接管瀏覽器或一般 TCP 流量，未必會自動接管 SSH。若網路環境不允許直接使用 SSH，可以改用 HTTPS，或依照組織允許的方式設定 SSH over 代理；不要下載來路不明的「一鍵 SSH 修復工具」。

大型儲存庫與 Git LFS

儲存庫的文字檔案可以正常抓取，不代表 Git LFS 物件也能下載。Git LFS 往往會先由 Git 取得指標檔，再向另一個儲存服務請求實際的大型物件。若只有部分檔案出現指標內容、下載停在某個物件，應查看 LFS 的錯誤訊息與實際連線網域，確認代理規則沒有隻涵蓋 GitHub 主站。

對團隊而言，較穩妥的做法是把「程式碼取得」與「大型資產傳輸」分開觀察。不要在同一時間更換代理節點、重寫 Git URL、刪除憑證並重新初始化 LFS，否則很難知道哪個變更真正有效。先保留原始錯誤，逐項調整，完成後再把可用設定寫入團隊文件。

  • ✅ 先確認遠端 URL 使用 HTTPS 還是 SSH，再修改對應設定。
  • ✅ 以 git config --show-origin --get-regexp 'http.*proxy|https.*proxy' 檢查代理來源。
  • ✅ Git LFS 失敗時，另外檢查大型物件服務，不要只測試 GitHub 首頁。
  • ❌ 不要把 Token、私鑰或完整訂閱連結貼到公開 issue 與聊天羣組。
一句話結論:GitHub 能否使用，必須分別驗證 HTTPS、SSH 和 Git LFS；瀏覽器可開啟並不能代表三者都已打通。

Docker：最容易忽略的是 daemon 不是終端機

Docker 的代理設定經常讓開發者誤判。你在終端機中設定了 HTTP_PROXY，可能隻影響目前 shell 裡執行的命令；而 docker pull、docker build 下載基礎映像檔時，真正發出請求的可能是 Docker daemon。Docker Desktop、Linux 上的 systemd 服務，以及遠端 Docker 主機，各自有不同的設定位置。

開始調整前，先分辨是「拉取映像檔」失敗，還是「建置過程中的 RUN 指令」失敗。前者通常需要讓 daemon 連到 Registry；後者則可能需要把代理以 build arguments 或建置環境傳入容器。兩者不能混為一談：daemon 能拉到 FROM 指定的映像檔，不代表容器內的套件管理器也能連線；容器內能執行 apt 或 npm，也不代表宿主機能完成 docker pull。

若使用 Docker Desktop，應在其設定介面檢查代理選項，完成修改後依提示重新啟動相關服務。Linux 主機則要確認 systemd 服務讀取到的環境設定，並在變更後重新載入服務。遠端 Docker 主機尤其要小心：你本機的代理只會影響 Docker CLI，不會自動改變遠端 daemon 的出口。

不要把代理憑證烘進映像檔

建置時若需要代理，應避免在 Dockerfile 中以明文寫入帳密，或把敏感設定留在映像檔 layer、shell history 和 CI log。可以依照建置平台提供的 secret、masked variable 或短期環境設定傳入，並在建置完成後檢查輸出是否意外顯示代理資訊。若只是讓映像檔下載通過代理，應優先修改 daemon 的出站設定，而不是把所有應用程式流量永久寫入容器。

Docker Registry 還可能涉及登入服務、映像檔清單與多個分層下載。遇到「認證成功但拉取失敗」，可以先判斷失敗發生在 manifest 還是 blob；遇到只有某個架構失敗，則要檢查多平台映像檔是否被拉到不同的 layer。這些情況不一定是代理本身故障，也可能是 Registry、權限或映像檔發佈流程的問題。

npm 與 pip：索引、相依套件和快取要一起看

npm 與 pip 都不只是「連到一個網站下載檔案」。npm 會先讀取 registry 的套件 metadata，再根據 package-lock.json 或其他鎖定檔取得相依版本；某些套件還可能從 Git URL、二進位資產或原始碼建置工具下載內容。pip 則會依照 index-url、額外索引和平台標籤選擇 wheel，找不到合適的 wheel 時，可能改為下載原始碼並在本機建置。

因此，設定代理後若 npm 可以取得 metadata，卻在某個套件 tarball 逾時，應檢查該套件的實際下載 URL，而不是立即更換整個 registry。pip 也一樣：索引頁面可讀取，不代表選中的 wheel 或原始碼主機一定可達。建議先以詳細輸出找出最後一個成功請求與第一個失敗請求，再針對該網域設定分流。

在個人開發環境，可以檢查 npm 的 proxy、https-proxy、registry 設定，以及 pip 的設定檔、環境變數和憑證來源。公司或團隊環境則應優先使用內部套件代理與快取服務，讓多名開發者和 CI 不必反覆從外部下載相同檔案。快取服務不等於盲目信任，仍要管理套件來源、簽章、掃描流程與更新政策。

代理與快取不是同一種解法

代理解決的是目前裝置到遠端服務的連線路徑；快取解決的是相同依賴是否需要重複跨網下載。若每次 CI 建置都從外部 registry 重新取得完全相同的內容，即使代理穩定，也會受到外部服務和跨境路徑波動影響。導入快取後，仍要保留 lockfile、校驗內容與失效策略，避免快取中的舊版本或不完整檔案造成另一種故障。

不要同時修改 registry、代理、lockfile 和套件版本。較好的操作方式是先在乾淨環境確認原始失敗，再只增加代理設定；若仍有問題，再單獨驗證快取或替代索引。完成後在本機與 CI 各執行一次，確認設定沒有隻對互動式終端機生效。

動手操作：建立一套可重複的加速與分流流程

以下流程適合排查 GitHub、Docker、npm 和 pip 的共同網路問題。它不依賴某個特定品牌的用戶端；Windows、macOS、Android、iOS 與 Linux 官方用戶端通常可以透過訂閱連結一鍵導入設定，Clash Verge、sing-box、Shadowrocket 等相容客戶端則應依各自介面確認代理模式和規則是否生效。開發環境通常以桌面系統或 CI 主機為主，手機用戶端可用來確認同一出口是否能正常連線，但不能取代伺服器端測試。

  1. 先記錄原始狀態。保存 Git、Docker、npm 或 pip 的完整錯誤訊息，註明使用的網路、作業系統、命令和失敗時間。不要只截取最後一行。
  2. 確認代理客戶端狀態。檢查是否已連線、目前出口地區是否符合用途，以及系統代理、TUN 模式或應用程式代理是否真的啟用。不要同時開啟兩個會接管系統流量的客戶端。
  3. 先做單一網域測試。使用瀏覽器或命令列測試目標網域的 DNS、TLS 與基本回應，再判斷是網路不可達、憑證問題還是程式設定錯誤。
  4. 建立最小分流規則。只把 GitHub、使用中的 Registry 或套件索引加入代理範圍，內部 Git、公司網域、區域網路和本機服務維持直連。規則名稱要能表達用途，方便日後檢查。
  5. 分別測試四項工作。先做小型 Git fetch，再測試 Docker manifest 或公開映像檔，接著測試 npm、pip 的索引和檔案下載。每次只改一項設定。
  6. 把成功設定移到自動化環境。CI 中使用平台的 secret 與 masked variable，設定 Docker daemon、套件管理器和 Git 的代理來源，並檢查 log 不會輸出憑證。
  7. 記錄回復方式。保留清除代理、還原 registry、重建快取和撤回規則的步驟。網路環境改變時，能快速回到直連基準比盲目累加設定更重要。

如果使用分流客戶端，建議先採用規則模式，而不是一開始就讓所有流量走代理。GitHub 的網頁、Git LFS、Docker Registry 和套件下載可能使用不同網域，因此規則應以實際請求為依據逐步補充。若使用 WireGuard，通常是以隧道和路由表控制流量；Shadowsocks、VMess、Trojan 與 Hysteria2 則常由相容客戶端建立代理連線。協議名稱不能直接代表 GitHub 或 Docker 的下載品質，真正結果仍取決於出口、路由、DNS、MTU 和遠端服務狀態。

  • ✅ 開發機與 CI 盡量使用一致的分流邏輯和套件來源。
  • ✅ 只代理需要的外部網域，內部資源保留直連。
  • ✅ Docker daemon、Git、npm、pip 分別確認設定是否生效。
  • ❌ 不要把系統全域代理、終端機代理和容器代理混成一個無法追蹤的設定。
  • ❌ 不要為了測試方便，把私有 registry 憑證寫進 Dockerfile 或公開設定檔。
一句話結論:最穩妥的加速不是「所有流量都轉送」，而是讓每個工具的出站請求走正確代理，並讓可重複下載的依賴優先使用可信快取。

團隊長期使用時的維護重點

一次成功不代表設定可以永久不管。GitHub 可能調整服務網域，Registry 可能增加認證流程，套件管理器也可能因 lockfile、憑證或 TLS 版本變化而出現新的錯誤。團隊應把代理設定、分流規則、套件索引、Docker daemon 配置和 CI secret 分開管理，並清楚標示哪些設定只適用於本機，哪些設定會影響所有建置工作。

訂閱連結應視為敏感的連線設定，不要直接放進公開倉庫、Docker image、CI log 或團隊 wiki 的公開區域。若使用官方用戶端，可在登入後依平台取得設定並匯入；若使用 Clash Verge、sing-box 或 Shadowrocket，則要核對訂閱來源、更新時間和規則模式。匯出設定前檢查檔案內容，避免把節點憑證和私人參數一併分享。

若你需要從多個地區測試 GitHub、Docker 或套件服務，可先選擇與實際使用者接近的出口，再比較直連、中轉和 IEPL 專線等路徑。JeVPN 支援 Windows、macOS、iOS、Android 與 Linux，覆蓋 90+ 國家、200+ 線路，同時在線設備不限台數；月訂閱有 ¥9.9/月含 60GB、¥18/月含 250GB、¥28/月含 500GB，流量按開通日每月重置，中途升級差價折算成剩餘天數。也可選擇用完為止、永久不過期的 ¥158/300GB、¥358/1000GB、¥658/3000GB 流量包，並提供首次付費不滿意的 14 天全額退款。