開發者網路提速完整方⁠案：GitHub、Docker、npm一次搞定

對開發者來說，網路速度慢不只是「網頁開得慢」這麼簡單：git clone 可能停在某個物件不動，Docker 映像檔拉取到一半逾時，npm 安裝又因為套件來源連不上而反覆重試。更麻煩的是，這些問題通常分散在不同工具裡，瀏覽器能開啟 GitHub，不代表終端機、Docker daemon 或 CI runner 也能正常使用。本文按照實際開發流程，整理 GitHub、Docker、npm，以及編輯器與 CI 環境的設定方法，讓你先判斷瓶頸，再選擇合適的代理方式，而不是每次遇到逾時就盲目重裝。

先判斷是哪一層變慢

開發工具的網路請求大致可以分成三層。第一層是瀏覽器或作業系統本身，例如瀏覽器可以開啟 GitHub 首頁，但這只代表瀏覽器使用的連線沒有完全中斷。第二層是命令列工具，例如 Git、npm、curl，它們通常讀取自己的代理設定，未必會自動沿用瀏覽器的設定。第三層是獨立服務程序，例如 Docker daemon、遠端開發容器或 CI runner，它們可能運行在另一個程序、虛擬機甚至另一台主機上。

因此，排查時不要一開始就修改所有設定。先在同一台裝置上確認網域解析、HTTPS 連線和工具本身的回應，再判斷問題屬於 DNS、代理、憑證、權限還是上游服務。以下幾個命令適合用作初步檢查：

curl -I https://github.com
git ls-remote https://github.com/example/project.git
npm ping
docker info

如果 curl 連不上，問題通常還沒進入 Git、npm 或 Docker 層；如果 curl 正常，但 git ls-remote 失敗，應該檢查 Git 的代理或憑證；如果 Git 與 npm 都正常，Docker 卻無法拉取，則要特別查看 Docker daemon 的代理設定。這種分層方式比反覆切換節點更有效，也能避免把本來是權限問題誤判成網路問題。

• ✅ 先確認網域能解析，再確認 HTTPS 是否能建立連線
• ✅ 讓 Git、npm、Docker 分別讀取適合自己的代理設定
• ✅ CI 環境單獨檢查 runner，不要假設本機設定會自動同步
• ❌ 不要同時開啟兩個代理客戶端，避免環境變數與路由互相覆蓋

GitHub：從 clone 到 Release 的連線設定

GitHub 使用場景不只有下載原始碼。clone 和 fetch 需要存取 Git 的遠端端點，Submodule 可能再呼叫另一個儲存庫，Git LFS 則會使用額外的物件儲存端點。也就是說，首頁可以載入，並不能證明整個專案的所有下載流程都正常。遇到大型儲存庫、很多 submodule 或 LFS 物件時，應該先確認是哪個遠端請求失敗。

如果使用 HTTPS 形式的遠端網址，可以為 Git 設定代理。命令中的埠號必須替換成你目前客戶端提供的本機 HTTP 或 SOCKS 監聽埠，不要直接照抄不存在的埠號：

git config --global http.proxy http://127.0.0.1:本機埠號
git config --global https.proxy http://127.0.0.1:本機埠號
git config --global --get-regexp 'http.*proxy'

若客戶端只提供 SOCKS5，也可以使用對應的格式。不同 Git 版本與作業系統對 SOCKS 代理的支援細節可能不同，設定後應用 git ls-remote 驗證，而不是隻看設定檔是否寫入。若某個儲存庫需要走直連，也可以在單一專案層級覆蓋全域設定，避免所有 Git 流量都套用同一條路徑。

git -C ./project config http.proxy http://127.0.0.1:本機埠號
git -C ./project config --unset http.proxy

SSH 形式的 GitHub 遠端則不會直接使用 http.proxy。如果團隊使用 [email protected]:owner/project.git，要在 SSH 設定中處理代理，或把遠端網址改成 HTTPS 後再使用 Git 的 HTTP 代理。修改前先用 git remote -v 查看目前形式，並保留原本的遠端設定，避免在不清楚協作方式時造成提交或驗證流程中斷。

Git LFS 也值得單獨測試。執行 git lfs env 查看 LFS 的端點與設定，再用小型專案確認下載是否成功。若普通 Git 物件可以取得，但 LFS 失敗，問題通常不在 clone 命令本身，而在 LFS 端點、代理規則或企業網路對大檔案請求的處理方式。

Docker：分清 CLI、daemon 與 registry

Docker 最容易讓人誤判的地方，是你在終端機輸入的 docker pull 並不一定由目前這個終端機直接完成下載。Docker CLI 通常會把請求交給 Docker daemon，而 daemon 可能是本機服務、遠端主機、Docker Desktop 內的虛擬環境，或 CI runner 上的獨立服務。你在 Shell 裡設定了 HTTP_PROXY，不代表 daemon 就會使用同一個代理。

先用以下命令查看 Docker 的執行環境與錯誤訊息：

docker context ls
docker info
docker pull alpine:latest

如果錯誤內容是解析 registry 失敗，應先檢查 DNS；如果是 TLS handshake、connection reset 或 i/o timeout，則應查看 daemon 的代理、系統時間與企業憑證；如果提示沒有權限，則需要處理 registry 登入，而不是繼續更換線路。私有 registry 還可能要求額外的憑證或登入令牌，網路通暢與否和身份驗證是兩件不同的事。

Docker Desktop 通常在自己的設定介面管理代理；Linux 上的 Docker Engine 則常透過 systemd drop-in 或服務環境檔設定。修改後必須重新載入服務，並用 docker info 確認配置是否生效。不要把 Shell 中的代理環境變數與 daemon 配置混為一談，也不要把包含密碼的代理網址直接提交到 Git 儲存庫。

除了拉取基礎映像檔，docker build 裡的 RUN npm install、RUN apt-get update 或下載其他依賴，也可能需要代理。這時要區分「daemon 下載映像檔」與「建置容器內的程序下載依賴」：前者改 daemon，後者要在建置階段透過明確的 build argument 或建置網路設定傳入。敏感憑證不應使用會被寫入映像層的方式傳遞，正式建置應優先使用 BuildKit 的 secrets 或 CI 的受保護變數。

npm：registry、代理與 lockfile 要分開看

npm 安裝失敗，常見原因包括 registry 連線不穩、代理沒有被 npm 讀取、企業憑證未被信任，以及 lockfile 指向的 tarball 網址無法存取。只把逾時時間調大，通常只能延後錯誤出現，不能解決根本問題。先查看目前 npm 的設定與套件來源：

npm config get registry
npm config get proxy
npm config get https-proxy
npm ping
npm cache verify

如果使用公開 registry，應確認 registry 設定指向團隊允許使用的來源；如果公司使用私有 registry，還要檢查 scope 映射，例如某個組織的套件是否應該從內部 registry 取得。不要為了繞過一次失敗，就在全域設定中永久改用來路不明的鏡像，因為套件完整性、版本同步和憑證管理同樣重要。

npm 的代理可以透過設定檔或環境變數提供。團隊協作時，建議把非敏感的 registry 規則寫入專案文件，把登入令牌放在使用者層級或 CI Secret，而不是提交 .npmrc 中的明文令牌。使用 lockfile 時，還要留意其中的 resolved URL；即使目前的 registry 設定已修改，lockfile 裡的下載地址仍可能指向原本的來源。

在 Docker 建置裡執行 npm 時，主機上的 npm 設定不一定會自動進入容器。可以先在同樣的基礎映像檔中測試 npm ping，再把必要的 registry、CA 憑證與代理規則以安全方式提供給建置階段。若本機安裝成功、容器內失敗，優先比較 DNS、憑證、環境變數和網路模式，不要先刪除 lockfile。lockfile 是重現依賴的重要依據，任意刪除可能讓版本解析結果改變。

動手設定：建立可回復的開發環境

下面是一個較穩妥的操作順序，適合 Windows、macOS、Linux 以及使用 Clash Verge、sing-box、Shadowrocket 等相容客戶端的情況。不同客戶端的介面名稱可能不同，但核心概念都是取得訂閱、選擇可用節點、開啟本機代理，然後讓各個工具明確使用該代理。

1. 先準備客戶端。從官方支援的 Windows、macOS、Android、iOS 或 Linux 用戶端開始；若使用相容客戶端，先確認它支援目前訂閱中的協議與配置格式。訂閱連結應只從可信任的帳戶或服務頁面取得，匯入後查看配置是否成功解析。
2. 選擇適合開發的路徑。Git clone、npm 安裝和 Docker registry 對穩定性都很敏感。先選擇靠近你與目標服務的地區，再在客戶端中比較直連、中轉或 IEPL 專線等類型。不要只看節點名稱中的城市，還要觀察實際工具是否能完成請求。
3. 先測試本機代理。用客戶端顯示的本機 HTTP 或 SOCKS 埠測試 curl，確認代理本身可用。若 curl 能夠完成 HTTPS 請求，再設定 Git 和 npm；Docker 則另外處理 daemon 層級配置。
4. 逐個套用工具設定。先設定 Git，執行 git ls-remote；再設定 npm，執行 npm ping；最後測試 Docker 的 context、daemon 與 registry。每完成一層就記錄結果，方便之後撤銷或比較。
5. 保存可回復設定。記下修改過的 Git config、npm config、Docker Desktop 或 systemd 設定。工作結束後，如果不希望所有流量持續經過代理，應關閉客戶端或移除全域代理，避免影響公司內網、私有 registry 或本地服務。

編輯器與 CI：不要假設本機設定會自動帶過去

VS Code、JetBrains IDE、遠端 SSH、Dev Container 和本機終端機可能各自擁有不同的環境。編輯器整合終端機通常會繼承啟動它的環境變數，但遠端開發主機使用的是遠端主機的網路；Dev Container 裡執行的 npm 或 Git，也可能完全看不到主機端客戶端提供的 127.0.0.1 代理。對容器來說，127.0.0.1 指向容器本身，不是宿主機，這是設定後仍然逾時的常見原因。

因此，使用 Dev Container 時要先確認容器能否解析宿主機地址，並按照目前 Docker Desktop 或 Linux 網路環境提供的方式傳遞代理。不要直接把宿主機的本機埠號硬編碼成團隊唯一方案，因為不同作業系統、網路模式和客戶端可能有不同差異。更好的做法是把必要的代理參數做成未提交的本機環境設定，專案只保留不含祕密的範例。

CI runner 更需要單獨設計。它可能位於雲端、公司內網或自建主機，不能使用開發者電腦上的代理。若 workflow 需要 clone 私有儲存庫、拉取容器映像檔或安裝 npm 套件，應在 runner 層級配置允許的出口、registry、憑證與快取策略。對公開依賴，可以使用受控的套件快取或企業 registry；對私有依賴，則用 CI 平台的 Secret 注入，並限制令牌權限與有效範圍。

還要注意 CI 中的平行工作。多個 job 同時拉取相同映像檔或套件時，瓶頸可能在 registry 限制、快取未命中或 runner 資源，而不是單純的跨網路延遲。可以先檢查日誌中的失敗階段：解析失敗、連線逾時、TLS 錯誤、未授權、digest 不一致，各自對應不同處理方法。只有保留清楚的錯誤分類，團隊才能判斷是需要調整代理、registry、快取還是權限。

成本控制與日常自檢

開發加速不等於所有流量都必須長期走代理。文件閱讀、程式碼同步、映像檔下載和套件安裝可以按照實際需求分流；公司內網、區域服務、本地資料庫與區域 DNS 則應依照團隊政策決定是否直連。規則越清楚，越不容易出現登入公司系統失敗、內網地址解析錯誤或本地服務無法存取的情況。

如果只是偶爾下載依賴，可以優先使用按月訂閱方案：¥9.9/月含 60GB、¥18/月含 250GB、¥28/月含 500GB，流量會按開通日每月重置；需要一次性處理大量下載，也可以查看 ¥158/300GB、¥358/1000GB、¥658/3000GB 的流量包，流量包用完為止且永久不過期。多台電腦或手機共同使用時，同時在線裝置數不限；付款方式支援支付寶、微信與 USDT，註冊不需要郵箱地址。

但選方案前仍應按照實際工作量評估，不要只因某次下載很慢就盲目購買更高流量。先確認是否存在無限重試、Docker 未命中快取、npm 重複解析或 CI 每次重新拉取映像檔等浪費來源。把問題修正後，實際流量消耗可能會下降，日常使用也更容易管理。

• ✅ Git 使用 HTTPS 或 SSH 前先確認遠端形式，兩者代理設定不同
• ✅ Docker 先檢查 context 和 daemon，再處理 registry 與 build 內的依賴
• ✅ npm 保留 lockfile，優先修正 registry、憑證與代理，不要隨意刪除依賴鎖定
• ✅ CI 使用獨立的 runner 設定與受保護 Secret，不直接複製本機配置
• ❌ 不要將 Token、訂閱連結或含認證資訊的代理網址提交到儲存庫