NetworkPanel 開源流量消耗器：把下載頻寬的極限逼出來

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

8 條執行緒、Cloudflare 測速節點，按下去大約 6 秒，總流量停在 246MB，即時速率 42.6MB/s，換算頻寬約 340Mbps。這是我在一台海外寬頻線路上，用 NetworkPanel（網路面板）實際跑出來的數字。它是一個開源的線上流量消耗器：官網 net.netart.cn 打開就能用，不用註冊，原始碼以 MIT 授權放在 GitHub 上，任何人都能免費自己部署一套。專案 2023 年 1 月就開張了，現在被 971 個人加星關注，作者署名 Whoami，頁尾註明網站由騰訊雲的 EdgeOne CDN 提供服務，算是個人專案裡部署得體面的一個。

「流量消耗器」這個品類對台灣讀者比較陌生，先花一段講清楚它存在的理由。這類工具流行的背景，是中國電信資費裡的定向流量設計：對特定 App 或特定 CDN 節點的流量免計費，或者方案要求每月用掉一定流量才解鎖全速。於是有人需要把流量「燒」掉，而且要燒在對的節點上。從節點清單的設計可以反推這個機制：電信商把自家體系的服務列入免計費範圍，手機對這些域名下載就不扣通用流量，所以「定向」的技術含義就是挑對域名狂下載。NetworkPanel 的官網關鍵字自己就寫著流量消耗器與定向流量消耗，測速與 IP 查詢反而是附帶的功能。台灣的資費幾乎沒有這種結構，你我其實不需要為了定向場景去用它，但把它當成下載方向的頻寬壓力測試器，倒是真的順手：它能瞬間把線路塞滿，讓你看到自己的下載極限在哪裡。

循環下載沒有魔術：讀完檔案就重來

我把原始碼 clone 下來讀了一遍。整個工具是 Vue 3 寫的單頁應用，核心邏輯集中在 src/components/Main.vue 的一個函式裡。它的做法說穿了很樸素：對選定的網址發出 fetch 請求，拿到串流之後不斷讀取，讀到檔案結尾就再開一輪，如此循環。請求本身帶了兩個講究的參數：不下載快取，確保每次都是真實傳輸；不帶來源資訊，被查的 CDN 看不到你從哪個頁面連過去。多執行緒的意思，就是同時開好幾個這樣的循環，官網用一條滑桿讓你調 1 到 64 條，預設 8 條。啟動之後加減執行緒會立即生效，不必停掉重來，這是 Vue 3 重寫版特有的改進，舊版行為沒有這麼即時，舊程式碼目前還留在 repo 的 old 分支上供對照。

計數的方式有個誠實的細節。每條執行緒會先看內容長度標頭（content-length），下載量超過檔案本身的長度之後，多讀的部分就不計入總流量。也就是說，畫面上那個 246MB 是按檔案長度公平計算出來的，不是把串流裡重複讀到的位元組灌水算出來的。

工具還給了兩個節流開關。一個是定量：設好 MB、GB 或 TB 之後，燒完設定值自動停，適合「這個月還差 3GB」這種明確目標，掛著背景睡覺，醒來它自己停好。另一個是限速：擔心把整條辦公室線路吃滿影響別人，可以先設一個每秒上限，原始碼裡的做法是每讀一塊資料就視情況暫停一下，讓平均速率貼著你設的數字。這兩個開關連同執行緒數、背景執行與自動執行的狀態，全部存在瀏覽器的 localStorage 裡，關掉瀏覽器下次打開，設定都還在。自動執行開關打開之後，頁面一載入就會直接開跑，搭配定量使用就是你自己的無人值守燒流量流水線。

值得一提的是它內建的黑名單。Main.vue 裡有一行 block_list，把作者自己的兩個域名加上 .gov.cn 結尾的政府網域全部列為禁止節點。你要是貼上這類網址當消耗目標，它會直接拒絕，還跳出一句半開玩笑的警告，說要拿小本本記下來交給警察。這一行等於作者自己畫了線：不能燒自己的伺服器，也不能拿政府網站當靶子。這種自帶邊界的設計，在同類工具裡不算常見。

黑名單之外還有一層責任邊界要自己認：內建節點燒的是商業 CDN 的公開測試端點，Cloudflare 與 Cachefly 本來就是設計來承受測量流量的，用它們當靶子天經地義。但自訂節點欄位是全開放的，你填誰的網址，誰的伺服器就得承受你開出來的幾十條執行緒。拿它去長時間掛別人的小站，那就跟壓力攻擊沒有兩樣了，工具給了節流開關，禮貌與責任得自己帶上。

節點清單攤開：燒的是電信商與 CDN 的公開檔案

流量到底燒到誰頭上？答案在 src/assets/nodes.json，內建節點全部是公開的大檔案下載連結，分兩組。一組按電信商分類：和彩雲（中國移動體系的雲端空間）的一張圖片，以及天翼雲桌面的 Windows 安裝程式，完整檔名還帶著版本號 2.3.0 與 x86 架構標記。這組是給定向流量場景用的，因為這兩個來源在中國的資費裡多半屬於免計費或定向計費的範圍。另一組是全球節點：Cachefly 的測試檔、Cloudflare 的 95MB 下載端點、Steam 與 Microsoft 的 CDN 圖檔。這份清單也有社群幫忙照顧，GitHub PR #27 把 Cloudflare 測試檔調整為 95MB，合併後寫進節點表。

你也可以新增自己的節點，貼上網址之後工具會先做一次可用性檢查，5 秒內等不到資料就不讓你啟動，並提示原因。自訂節點清單只存在瀏覽器本地，不過一旦把自訂節點選為消耗目標，它的網址就會隨每分鐘一次的使用上報送進作者後端。更貼心的是它在頁面上掛了剪貼簿監聽，你複製好連結再切到頁面貼上，它會自動抓連結、驗證可用性，省一次手動輸入。

不過這份清單在台灣用起來有一個很實際的落差：電信商那組節點是為中國境內的定向流量場景服務的。我逐一實測，和彩雲的圖片境外連線 12 秒逾時，完全拉不動；天翼雲的安裝檔境外連得上，實測速度約每秒 5MB，只有國際節點的八分之一左右；全球節點倒是全部健康，Cachefly 與 Cloudflare 都正常吐資料。main 分支 7 月還有一條標題叫刪除失效節點的維護紀錄：節點會死，清單得一直養。對你我來說結論很簡單，定向燒流量的玩法只存在於中國境內的線路環境，境外能用的，是它當頻寬壓測器的這一面。

啟動之前，先知道它每分鐘上報什麼

這是讀原始碼才看得到、也最該先講清楚的一條邊界。Main.vue 裡有一個 uploadLog 函式，執行期間每 60 秒對作者的後端 app.netart.cn 發一次 POST，內容包含你選的節點網址、執行緒數、這一分鐘燒掉的流量、經過時間，外加登入憑證。榜單功能就是靠這些資料疊起來的：登入方式是填 QQ 號，頭像直接從騰訊的頭像服務拉過來展示，誰這個月燒得兇，榜上見真章。也就是說，這個上報機制一半是遙測、一半是遊戲化的燃料，參與榜單的人等於自願把用量攤在陽光下。另外有個細節：榜單上分享的節點網址可以只寫主機名，實際下載網址由後端動態解析給出，每分鐘刷新一次，節點失效時作者端可以直接換掉，不必等你更新頁面。

關鍵在於，判斷「有沒有登入才上報」的那個 if 條件，在原始碼裡是被註解掉的。就算你從沒登入過，每分鐘一次的上報照樣發出去。它不算偷偷摸摸的行為，打開瀏覽器開發者工具就能看到這個請求，但「純前端工具」這五個字在這裡要打折扣：頁面確實不需要後端就能跑，使用紀錄卻會送進作者的伺服器。榜單本身做得挺認真，從後端介面的參數看得出來，分小時、天、月、年四種週期，還能按總流量、平均速度或上線時長排序，是照著認真營運的社群在做的。

想自己架一套擺脫上報的人，還有一個容易踩的坑。GitHub 上的 Dockerfile 是把建置好的靜態檔放進 nginx 映像檔，一行 docker run 就能起服務，看起來最省事；README 還提供另外兩條路，直接下載建置完成的壓縮包丟到任何靜態主機，或用騰訊雲的頁面服務一鍵部署。但無論哪條路，後端網址都是在建置階段就寫死進套件的環境變數，官方產物裡那個網址仍然指向 app.netart.cn。要真的斷掉上報，得 clone 原始碼、改掉 .env 再自己重新建置。Docker 一行不等於斷線，這中間的差別值得記住。榜單與登入那些後端功能自架版本不會有，它們從頭到尾都掛在作者的伺服器上。

從台灣線路實跑：預設節點逾時，換 Cloudflare 才跑得動

實際操作的感受比讀碼直觀。頭一次按下啟動鈕時我什麼都沒改，用的是預設的和彩雲節點，畫面右上轉了一下圈，跳出連線逾時的錯誤，沒有跑起來。原因就是前面說的：預設節點對境外連線逾時，5 秒可用性檢查直接判死。把測速地址換成 Cloudflare 之後再按一次，數字立刻活了起來，總流量、即時速率、頻寬三個欄位同步跳動，6 秒後按停，就是開頭那組數字。順手做個交叉驗算：42.6MB/s 換算位元是 340.8Mbps，畫面頻寬欄顯示 340Mbps，兩個數字對得起來，間接印證前面說的公平計數沒有灌水。按停的瞬間它還會結算這一輪的平均速率，我這輪是 41.9MB/s，與即時值差距很小，表示線路在這幾秒內是穩定跑滿的。設定列裡另有個圖表開關，打開之後會用 ECharts 畫出速率曲線，原始碼裡看得到對應的實作；這次實測我把畫面留在數字檢視，曲線功能就留給有興趣的人自己開。

Pin

跑起來之後有個小設計很討喜：瀏覽器分頁的標題會即時顯示累積流量與速率，把分頁切到背景，不用點開來也能盯進度。手機上的背景執行則用了一個老技巧，循環播放一段極短的音檔讓系統不要凍結頁面，再配合防休眠的 NoSleep.js 函式庫，iPhone 上掛著背景燒流量是可行的。Android 另有官方的原生 App 版，官方說明強調螢幕關閉時可繼續執行、通知列能即時查看網路資訊，偵測到 Android 環境才會顯示下載入口，安裝時還會引導你把它加進電池最佳化白名單，避免系統中途掐斷。

Pin

官網的另一個賣點「多出口 IP 查詢」，這次體驗要打問號。先說這功能的立意：同一台裝置走不同連線或不同網路層，對外用的 IP 可能不止一個，它能讓你一次看清自己有哪些出口。首頁的 IP 資訊區塊從頭到尾停在載入中，問題出在作者的後端：IP 查詢與榜單讀取兩個服務持續報錯（HTTP 500），節點解析倒是正常應答。翻 issues 紀錄，IP 介面故障不是新聞，2024 年與 2025 年都有人反映過同樣狀況，屬於反覆發作的老毛病。這個功能的原理其實有意思：前端會對 Cloudflare 的 trace 端點發小請求，量出口的延遲與 IP，但 IP 歸屬地查詢這一步依賴作者的單一後端，端點一壞，前端就只能一直轉圈。功能設計有想法，可靠度跟不上。

上行不測、後端單點：先講好的限制

把它當頻寬壓測器用之前，有幾件事要先擺上桌。

上行完全不在設計裡。issues 裡 2024 年與 2025 年各有一條希望支援上行測速的建議，一條已被關閉、一條還開著，至今都沒實作，startThread 的邏輯也只有下載。你要驗證的是上傳頻寬的話，這個工具幫不上忙，得走 iperf3 那類需要自架伺服器的方案，或者參考我們之前寫過的 網路品質測試工具 介紹。

發版紀律很鬆散。main 分支 2026 年 7 月一連推了 v3.2.4 到 v3.2.7 四個版本，看得出有人在顧，但 GitHub 上零個 release，repo 裡 package.json 的版號還停在 3.2.2，落後 commit 裡的標籤。想知道自己用的是哪版，以官網畫面為準比以 repo 為準可靠。

後端是單點。上報與榜單靠 app.netart.cn，IP 查詢也靠它，這台後端一掛，榜單與 IP 功能一起消失，只剩純消耗的主功能不受影響。971 個 star、228 個 fork 的專案規模，配上這種中心化依賴，穩定性要自己打折看待。

資料落地要看清楚。你的節點偏好、執行緒數、定量設定都存在瀏覽器本地，這部分乾淨；但實際使用時的統計會離開瀏覽器進作者後端，兩件事別混為一談。

壓測、驗限速、看隧道吞吐：它派上用場的場合

想了一下，這工具在我們的網路環境裡有幾種實際用法。想驗證電信商承諾的下載速率的人，選一個國際節點、開滿執行緒跑個十秒，頻寬欄位就是你要的答案。多數測速網站用漸進大小的少量請求量測，我們介紹過的 Cloudflare 官方測速 就是同一個下載端點、以漸進大小的多次請求量測；NetworkPanel 的差別是把主導權交給你，執行緒要幾條開幾條，直接拉到管道極限。掛了 VPN 的人也可以連著隧道跑它，量出來的就是加密通道的實際吞吐，比帳面速率誠實得多。懷疑自己的線路被限速的人同樣能用它驗證：設定速率上限之後觀察實際速率貼不貼得住，比憑感覺申訴有底氣。自己架站或管宿舍、辦公室網路的人，可以在不同時段跑它觀察速率波動，把數字記下來跟線路商談判用。寫前端的人，它的原始碼本身就是一份乾淨的教材：串流讀取、公平計數、瀏覽器背景保活、剪貼簿事件，都是真實專案裡用得上的技巧，MIT 授權讓你可以整段拆來研究。

反過來說，如果你的需求是測上行、看延遲抖動，或者想要一份電信商等級的測試報告，它都不是那個工具。要是你一年只測一兩次速率，開瀏覽器跑個單次測速就夠，不必動用幾十條執行緒；會需要 NetworkPanel 的人，要的是「受控的大流量」這件事本身，無論是量隧道吞吐、驗證限速，還是純研究它的實作。它做的事情就一件：用循環下載把你的下載管道塞滿，然後誠實告訴你塞進去了多少。頻寬聚合或多線路備援 那類需求，也是另一個世界的事。

MIT 授權、零帳號門檻、原始碼攤在陽光下，這幾件事讓它成為同類工具裡少見的透明樣本。用之前記得兩件事：跑的時候每分鐘有一次使用紀錄送進作者後端，想斷乾淨就自己建置一份；還有別忘了確認你選的節點對你自己是不是免計費，畢竟它燒的每一個位元組，終究會出現在你的帳單邏輯裡。