Back to notes
Tech sharePythonCrowdsourcingGoogle Apps ScriptCDN

如何透過群眾測速自動迭代 B 站 CDN 選線品質

一支 Windows 測速程式怎麼在各地使用者家裡測 299 個 B 站節點、用分層影片和三段漏斗挑出最穩的 10 個當場寫進擴充,再把報告送回開發者,依業者市占加權改進各國預設節點,並照分析結果去補缺樣本的業者。

Updated 18 min18 viewsArticle language

我一個人只能測我家那條網路。所以我做了一支測速程式請各地的人在家跑:測完當場挑好他們家網路最穩的 10 個節點,同一份結果也寄回給我,拿來改所有人的預設。

你在 B 站按下播放,影片不是從「B 站」下載的。B 站會給你一個影片網址,播放器再去那個網址一段一段抓。這種專門送影片的網址,B 站手上有幾百個:有的是 B 站自己的機房,有的是華為雲、Akamai 這類外包的服務,每個網址背後可能有好幾台機器。業界叫它們 CDN 節點,下面都簡稱節點。

在海外,B 站分給你的節點常常很慢:熱門片還行,冷門片卡成狗 (原因在上一篇講過)。

所以我做了一個瀏覽器擴充「嗶速 - 海外影片加速 for bilibili」,做的事很單純:把影片換到比較快的節點下載。擴充裡每個國家內建一份節點清單,清單第一個是預設節點,裝好就直接用它,不用設定。大部分人裝完不會打開設定,所以預設選得好不好,決定了大部分人的體驗。

難的是挑。哪個節點最快,要看你家用哪一家網路業者。同一個節點,中華電信的用戶拿來看 4K 幾乎都沒問題,凱擘的用戶大多跑不動 (後面有實際數據)。

問題是我人在新加坡。

我能測的只有我自己家的網路。開 VPN 模擬台灣? 測到的是 VPN 機房的線路,不是中華電信、凱擘、中嘉的家用線路。299 個節點 × 每個國家每一家業者,我一個人測到明年也測不完。

只能請當地的人幫忙測。所以我做了 CDNSpeedTest.exe,一支 Windows 測速程式。

NOTE

一份測速結果,走兩條路回來

  • 短回程,給測速的人自己:測完當場挑出你家網路最穩的 10 個節點,寫進你擴充裡的「自訂節點列表」。在擴充選單切到這個列表就能用。
  • 長回程,給所有人:同一份報告寄回給我,跟同國家、同業者的其他報告合起來分析,改進擴充內建的各國清單和預設節點,跟下一版一起發出去。

標題說的「自動迭代」指的是長回程這個循環:收報告、分析都是腳本在跑,我只在最後決定要不要改。報告越多,預設越準;沒有資料的國家和業者,也一份一份補上。

這篇照這個順序講:

  1. 測速程式在你的電腦上做了什麼
  2. 怎麼從 299 個節點挑出「最穩的 10 個」,並當場送回你的擴充
  3. 結果怎麼回到我這邊,讓預設清單越來越準、照顧到越來越多人

怎麼參加測速請看參加教學,這篇不重複。

測速程式在你的電腦上做了什麼

幫我測速的人大多不寫程式。叫他們裝 Python、開終端機、貼 cookie,大概第一步就關掉了。

所以測速核心用 Python 寫 (只用標準函式庫,命令列就能跑),外面再包一層 tkinter 的視窗介面,用 PyInstaller 打包成一個 20 MB 左右、免安裝的 exe。雙擊、一路按下一步就好,有新版會自己更新。

測一次要 20 分鐘到快兩個小時,看你的網速。為什麼那麼久? 因為不是拿一支影片測 299 個節點、挑最快的來呼嚨。

一輪測速:299 個節點篩到 10 個 · 在 Miro 開啟

前兩步在擋髒資料,第三步避免只拿熱門片測出假象,後面每一關再篩掉一種「假快」。圖上沒看懂的詞 (403、梯隊、同池) 下面都會講到,先有個全貌就好。

NOTE

下面的 exe 截圖都是用假資料拍的,IP、業者、email、進度數字都是示意。

① 網路檢查:先確定這份資料能用

每份報告之後都會拿去挑某個國家的預設節點和清單。一份測錯的報告混進去,影響的是那個國家同一家業者的所有使用者。

所以開始前先花 20 到 30 秒檢查網路。紅框 1 是畫面上看得到的三項 (VPN、下載速度、延遲;延遲只是參考),紅框 2 是過關後依你的網速估出來的測速時間。下面第三項 DNS 是在背景檢查的,畫面上看不到。右上角的「步驟 3 / 7」是精靈的頁數,跟流程圖的編號無關:

網路檢查頁:紅框 1 是 VPN、下載速度、延遲三項結果,紅框 2 是通過訊息與預估測速時間

有沒有開 VPN。開了 VPN 就不是在測你家的網路了。程式會從 IP、電腦的網路設定等好幾個角度交叉判斷。

總頻寬夠不夠。用 speedtest.net 量:4 條連線同時下載起跳,速度還在漲就加開,最多 32 條;每 0.2 秒記一次速度,去掉最快的 10% 和最慢的約 22% 再平均。加開連線是被新加坡 M1 行動網路逼出來的:它每條連線限速約 25 Mbps,固定 4 條只量得到 100 Mbps (Mbps 是網速單位,數字越大越快),手機上的 Speedtest App 量到 361。

為什麼要量總頻寬? 因為後面會同時測好幾個節點,大家分你家這條網路。總頻寬太小,快的節點全被你家網路卡住,30、40、50 Mbps 這些對 4K、8K 還有差別的節點會擠成同一級,排名就沒意義了。參加抽獎的門檻訂在 50 Mbps,就是為了保住這段差距。

幫你查網址的 DNS 在不在當地。DNS 是把網址翻成 IP 的服務。B 站有些節點網址會看「是誰來查」給不同的 IP。開了 VPN 或改用公共 DNS,查詢可能被當成別國的人,分到別國的機器,測出來的結果不代表當地。

程式會查出替你查 DNS 的伺服器在哪個國家、有沒有附上你大概的位置 (這個欄位叫 ECS)。不在當地又沒附位置,就改用 Google 的加密 DNS,自己附上你的位置。這只讓報告代表「用當地 DNS 的大多數人」;如果你自己把 DNS 改成公共 DNS,看影片時拿到的機器還是可能不一樣。

NOTE

測速目的分兩種。單純測試 (只想替自己建列表) 網路檢查只顯示警告、可以繼續;參加抽獎 (我有辦禮物卡抽獎招募測速) 頻寬不到 50 Mbps 或偵測到 VPN 就不能往下。兩種報告我都收,但偵測到 VPN 的報告收信時直接丟掉,不會進分析。

② 掃碼登入:為什麼不能用 480P 測?

B 站沒登入只給 480P 以下的影片檔。

速度是用下載量除以時間算的,跟畫質無關,那為什麼不能用 480P 測? 因為不同畫質是不同的檔案,在節點上有沒有存著也不同。大家實際在看、實際會卡的是 1080P 以上的檔,這些檔比 480P 更常不在節點上、要回中國的機房調。拿 480P 測出來的結果,代表不了你按下播放時碰到的狀況。

所以一定要登入,而且沒有「略過」選項。用 B 站 App 掃 QR code 就好。紅框框起來的那句,是程式自己寫在畫面上的說明:

用 Bilibili App 掃 QR code 登入的畫面,紅框標出「登入資訊只留在這台電腦的記憶體,不會傳送」(QR code 為示意)

NOTE

登入的 cookie 只留在記憶體裡交給測速用,不寫檔、不上傳,程式關掉就沒了。測到一半登入失效會直接中止,不會偷偷降成 480P 繼續跑。

③ 挑影片:熱門、冷門都要測

節點對熱門片和冷門片的表現可以完全不同:熱門片早就存在節點上,冷門片要臨時回中國調。所以影片要分層挑。

程式先從 B 站的熱門榜、入站必刷,加上翻很深的搜尋結果,建一個影片池 (只收 2 分鐘以上的,太短的檔案量不出速度)。再依「播放量 × 發布時間」切九格,每格挑一支:

近(30 天內)中(3 年內)遠
高播放(≥ 100 萬)1 支1 支1 支
中播放(≥ 1 萬)1 支1 支1 支
低播放1 支1 支1 支

九格加一支中播放,共 10 支拿來細測。另外挑 3 支當下最熱門的拿來快篩、1 支低播放的拿來探測冷門片。三組互不重複,免得快篩時就先把細測影片「熱」起來了。畫質在 1080P 以上隨機挑。

④~⑥ 三段漏斗

299 個節點一個一個測太慢,要同時測好幾個 (同時測幾個叫並行數)。但同時測太多,好節點會一起撞到你家頻寬的天花板,大家都一樣快,排名又沒意義了。所以並行數是算出來的:

並行數 = 總頻寬 × 0.5 ÷ B 站單一連線速度(取整數,限制在 1~8)

「B 站單一連線速度」是測速開始時,先挑幾個常用節點,各用一條連線下載一段,取中位數。

測速頁會把整個流程拆成 9 個小步驟 (多了偵測網路、量頻寬上限、產生報告這些雜事),所以畫面上的「6/9 快篩」就是上面圖裡的 ④:

測速中的畫面:紅框 1 是第 6/9 步快篩與進度 450/897,紅框 2 是已經過與預估剩餘時間,紅框 3 是最新一行進度記錄

紅框 1 的 897 是 299 個節點 × 3 支影片,一筆一筆算。紅框 2 的剩餘時間會一路修正:每完成一步、快篩途中每 30 秒,都用實際量到的速度重算一次。紅框 3 是最新一行記錄,等一下會講。

④ 快篩:299 個節點 × 3 支熱門片 × 各下載 2MB。三支都成功的才往下走。

連不上的節點最浪費時間:每次都要等 10 秒逾時,還佔著一個並行名額。所以快篩前先用 64 條連線同時對所有節點「握個手」(只建立連線、不下載),握不上的直接跳過。握得上、下載時才卡住的,還是只能等逾時。

⑤ 冷門探測:快篩通過的節點 × 1 支冷門片 × 1MB。回 403 (伺服器直接拒絕) 的出局。

這一步是踩坑踩出來的。舊版快篩完只留速度前 80 名,結果前 80 名裡一半以上是「只能播熱門」的節點:熱門片超快,冷門片直接 403。真正能用的反而被擠出去了。

⑥ 細測:剩下的節點 × 10 支分層影片 × 4MB,每筆最多 8 秒,超過就用已經收到的部分算速度。很慢的節點 (不到 5 Mbps,連 1080P 都不順) 量 8 秒就夠知道它慢了。

速度從收到第一個 byte 才開始算,不含等回應的時間。2MB、4MB 對快節點只要零點幾秒,量不太出 60 Mbps 以上的差別,但我量過 B 站 8K 串流的碼率,依影片落在 12~59 Mbps,播放用不到更快,夠用了。

測試順序會隨機打亂,降低時段波動、還有同家族節點共用快取 (前一個節點把影片「熱」起來) 造成的偏差。每一筆測完就寫進檔案,中斷了重跑會從斷掉的地方接著測。

TIP

測速頁有個「詳細記錄」按鈕,會即時列出每一步的開始、完成和耗時;卡在等逾時的時候,也會寫出正在等哪個節點、等了幾秒。分得出是當掉還是在等,報告送回來時我也看得到時間花在哪。

詳細記錄視窗:紅框 1 是快篩前同時試連所有節點、連不上的直接跳過,紅框 2 是每 30 秒一行的進度與正在等的節點

紅框 1 就是上面說的「先握手」,連不上的節點後面的下載直接跳過。紅框 2 是每 30 秒一行的進度,寫出正在等哪個節點。

怎麼從 299 個節點挑出「最穩的 10 個」

這裡的「穩」有兩層:

  • 單一節點穩不穩:10 支影片不能有失敗,速度不能忽快忽慢。
  • 10 個放在一起穩不穩:預設那個哪天不順,你換到下一個時,下一個不要跟著一起掛。

單一節點:平均最快的不一定最好

細測完,每個節點手上有 10 支影片的速度。直覺是取平均、排名、拿前 10 個。不行:

平均最快,不一定排第一 · 在 Miro 開啟

圖上每一列是一個節點,每個點是一支影片的速度。規則照圖從上往下:

  • 10 支有任何一支失敗,不排名 (節點 A)。看到一半黑畫面,比慢還糟。
  • 忽快忽慢的,標成「不穩定」 (節點 B)。具體是標準差 (速度的分散程度) 超過平均的一半。熱門片極快、冷門片極慢,平均值沒有代表性。
  • 最快的「穩定」節點當基準 (節點 C)。其他節點跟它差多少,要跟「10 支影片本身的起伏」比:差距小到可能只是運氣 (約 2 倍標準誤,也就是平均值本身的誤差範圍),就一樣算「第一梯隊」(節點 D)。測不出差別的,就不硬分高下。
  • 達到基準一半速度的算「可用」(節點 E),剩下的是「差」(節點 F)。

另外,平均速度已經吃滿「總頻寬 ÷ 並行數」九成的節點也直接算第一梯隊:它是被你家網路卡住,不是節點慢。

WARNING

老實說這套規則有幾個毛病。10 支影片是故意分層挑的,熱門和冷門本來就會差很多:一個「熱門 200、冷門 50」的節點標準差一定大,會被標成不穩定,排在一個平平穩穩 40 Mbps 的節點後面,但它最慢的那支都比對方快。另外兩個節點測的是同一批影片,嚴格來說應該逐支相減再比;現在的算法把誤差範圍估得偏寬,第一梯隊可能收得太鬆。目前的取捨是寧可保守:不穩定的節點不會被選成預設,但還是會進列表墊後。

第 1 個是預設節點:第一梯隊裡,波動小 (標準差不超過平均的 3 成)、回應時間不慢的節點中,平均最快的那個。條件找不到就逐步放寬。

10 個放在一起:為什麼不是直接取前 10 名?

先講「池」。B 站自己的機房,網址長得像 cn-hbwh-fx-01-01,前四段 (cn、地點、電信、叢集) 一樣的算同一個家族,也就是同一個機房;其他節點看它的 CNAME 分組 (CNAME 是網址的「本名」,很多不同的節點網址其實指向同一個雲端服務),例如華為雲一般池和華為雲冷資料池是兩個池。解析到完全相同 IP 的再合併。

同一個池的節點,背後是同一批機器。如果前 10 名全在同一個池,那個池一出事,10 個一起掛,等於只有 1 個。

所以挑法是照排名往下取,同一個池最多 2 個,池滿了就跳過、換別的池補上:

10 個名額,同一個池最多 2 個 · 在 Miro 開啟

排名順序是預設節點第一,之後第一梯隊 → 可用 → 不穩定 → 差,同一級裡依平均速度。寧可往後收不穩定、甚至差的節點墊底,也要湊滿 10 個、分散到不同池。所以「最穩的 10 個」精確地說,是「前面幾個最穩、整份清單不容易一起掛」。

這條規則有數據。在當時收回來的 33 份報告裡,同家族的節點「一起失敗」的比例是 99%,不同家族也有 64%;同一個 CNAME 是 82%,不同 CNAME 37%。這量到的是測速當下的失敗,很多時候是「這條網路連不到那批機器」,機房臨時出事會不會一起掛,測速資料量不到。所以分池只是降低一起掛的機率,不是消除。但全部挑同一池,就真的等於只有一個節點。

這 10 個怎麼送到你的擴充 (短回程)

測完會先列出這次要送的內容:紅框 1 是建議的 10 個節點,紅框 2 是要寫進哪個瀏覽器的擴充。按下紅框 3,報告寄給我,同時把這 10 個寫進你的擴充:

發送前的確認頁:紅框 1 是建議的 10 個節點,紅框 2 是要寫入的瀏覽器,紅框 3 是「發送並建立自訂列表」按鈕(IP、ISP、email 為示意)

寫入擴充跟發送報告是故意綁在一起的:想拿到自己的節點列表,就要把報告回饋回來。你這份報告會拿去改善同一家業者其他人的預設,下一個人的報告也會改善你的,循環才轉得起來。按「不發送」,報告不上傳,也不會建立自訂列表。(反過來可以:取消勾選紅框 2,就只送報告、不寫入。)

問題是瀏覽器不讓外部程式寫擴充的資料。

我的做法是讓 exe 用你的瀏覽器開一個 B 站網址,節點放在網址的 # 後面 (# 後面的部分不會送到 B 站的伺服器,只有頁面上的程式讀得到)。

擴充本來就會在 B 站頁面上跑。它讀到這段 # 就先從網址上清掉 (免得重新整理又匯入一次),再把節點加進「自訂節點列表」:只收它本來就認得的 B 站節點,已經在列表裡的不重複加,新的接在後面。頁面上方會跳一個結果提示,那才是真正有沒有寫進去的依據;exe 只負責開網址,感謝頁的訊息是它開完網址後顯示的:

感謝頁:紅框標出「已在瀏覽器開啟 B 站,節點已加入自訂節點列表」

匯入不會幫你切換模式。打開擴充選單,把「CDN 節點」切到「自訂節點列表」,就是測出來的節點 (下拉選單要往下捲才看得到全部):

擴充選單選「自訂節點列表」,下拉選單裡是測出來的節點

(這張截圖和上面的確認頁是不同次測速拍的,所以節點不一樣。)

exe 這邊要先知道哪個瀏覽器裝了擴充:Chrome、Edge 讀每個設定檔的 Preferences,Firefox 讀 extensions.json,找到就開在裝了擴充的那個設定檔。還沒裝的話,感謝頁會附各商店的安裝按鈕,裝好再按「建立自訂列表」重試。

結果怎麼回到我這邊,讓預設清單越來越準、越來越全

短回程只照顧到測速的人自己。但測速的人花了 20 分鐘到快兩小時,測出來的東西對同一家業者的其他人一樣有用。這就是長回程:

一份測速結果的兩條回程 · 在 Miro 開啟 · 圖示:Microsoft Fluent Emoji(MIT)

圖上的 cdn-list.json 就是擴充內建的各國節點清單。

報告怎麼送回來

我沒有伺服器,也不想為了收報告去養一台。

收件端是 Google Apps Script (Google 的免費雲端腳本服務),部署成一個網頁應用程式,用我自己的 Google 帳號執行。exe 把報告 (REPORT.md)、結構化結果 (summary.json)、詳細記錄 (run.log) 包成一個 JSON 送過去,Apps Script 做這幾件事:

  1. 確認是測速程式送來的報告,不是的就拒收。
  2. 把三個檔案當附件寄給我自己,主旨帶國家、業者和 8 碼報告編號。
  3. 另存一份到雲端硬碟,再在試算表新增一列。
  4. 使用者有填 email 的話,寄一封確認信。

試算表那步有個小坑:appendRow 會自動轉型,報告編號 089934e2 會被當成科學記號變成數字。所以要先把文字欄設成純文字格式再寫入;「設格式再寫入」是兩個動作,再加 LockService 鎖住,免得兩份報告同時到時交錯。

NOTE

隱私:送回來的報告,內容是「某家網路業者連 B 站各支影片的速度」,認不出是誰測的。IP 只拿來判斷國家、業者,以及合併同一條線的重複測試。email 只有參加抽獎才需要填,用來寄確認信和禮物卡;除此之外,跟改善節點清單無關的個人資料我一概不收。Wi-Fi 不記名稱,B 站帳號資訊一個字都不送。同意隱私聲明之前程式什麼都不送,上傳成功後,關閉程式時本機的結果也會刪掉。

收信、歸檔、分析都是腳本,最後我決定

報告收進 Gmail 之後,後面兩步都是腳本 (我把它們做成 AI 寫程式工具 Claude Code 的兩個指令,名字前面的 / 就是這個意思):

  1. 收信歸檔 (/collect-speedtest-mail):從 Gmail 撈出測速信,驗附件,丟掉重複的、偵測到 VPN 的報告,依國家歸檔到本機,處理完的信移到垃圾桶,下次只會看到新信。
  2. 跨報告分析 (/analyze-cdn):把同一國的所有報告合起來,產生一份分析報告。

單份報告回答的是「這條網路最好的節點是哪個」。擴充內建的清單要回答的是另一個問題:這個國家的人剛裝好、什麼都還沒設,預設哪個節點最不容易出事?

分析腳本做這幾件事:

  • 合併重複測試:同一家業者、同一個出口 IP (你上網時對外顯示的 IP)、而且結果一致的報告,當成同一條線路測了好幾次,只算 1 份樣本。不然有人連跑三次,那條線的權重就變三倍。
  • 判斷「達標」:一個節點在一份報告裡的速度夠看 4K (門檻大約 22 Mbps),就算達標。不穩定、失敗、只能播熱門的都算不達標。
  • 排除量測壞掉的報告:快篩通過不到 30 個節點 (多半是 DNS 或網路有問題)、或頻寬上限不到 30 Mbps 的,自動排除,並列出來讓我決定刪不刪。
  • 行動網路分開算:手機熱點、5G 家用寬頻跟同一家業者的固網是不同的網路,節點好壞常常相反,所以獨立分組,不算進預設,只在後面輪流挑節點時補洞。

然後挑預設節點。用台灣 2026-10-25 的資料 (106 份報告、16 家固網業者,另有 2 家行動網路) 看就知道為什麼難:

台灣:沒有一個節點對每家業者都好 · 在 Miro 開啟

台灣的業者大致分成兩大陣營:中華電信適合一批節點 (江西南昌那個是中國移動的機房,在中華電信 41 條線路全部達標),其他業者幾乎都適合另一批 (山東濟南、湖北武漢在凱擘、台灣寬頻通訊 TBC 和其他小業者幾乎全部達標),但這批在中華電信只有一半達標。第二大的中嘉兩邊都不太行,後面再講。沒有任何一個節點能讓所有人都順。

所以預設節點看的是覆蓋率:每家業者「達標的比例」乘上它的市占,加起來。市占用 NCC (國家通訊傳播委員會)、業者財報這類公開統計,不能用收到的報告數量推 (不然誰報告交得多誰說了算)。中華電信市占最大,但其他業者加起來也不小,所以覆蓋率最高的反而是武漢 (65%),不是中華電信最愛的南昌 (63%)。

剩下 9 個名額,讓每家業者依市占輪流挑:每一輪,每家從「自己的第一梯隊」裡挑一個還沒入選的。這裡的第一梯隊是把那家業者所有線路的結果合起來排的,跟單份報告的分級是同一套想法,所以是相對的:拿那家業者自己最好的節點當基準。中華電信的第一梯隊裡分數最高的是華為雲:南昌雖然全部達標,華為雲更快。中華電信先挑、中嘉第二…輪完一圈再輪第二圈;清單裡已經有某家的第一梯隊了,那一輪就跳過它,把名額留給還沒被照顧到的業者。

預設照顧不到的人,就在這份清單裡換:擴充選單可以手動換節點,也可以按「測試各節點速度」把清單測一遍再挑。

IMPORTANT

「自動迭代」裡唯一不自動的是最後一步:要不要改清單,我自己看完分析報告再決定。腳本的建議清單是從零挑的,很多節點分數接近,名次一動入選的就換人。「建議清單跟目前清單差 6 個節點」不等於「效果差很多」。

這次台灣的分析就是例子。腳本建議把預設從山東濟南換成湖北武漢,覆蓋率 63% → 65%。但只差 2 個百分點;拿這些線路重抽樣 (隨機抽一部分線路重算很多次,看結果穩不穩),被選成第一名的機率分散在好幾個節點,算打平,所以預設不換。固網的部分逐家比過,每家業者在目前清單裡最好的節點都已經是第一梯隊,也不換。

最後只改了一個地方:清單最後一個 cn-sccd-fx-01-01 對每家業者都是「差」,換成 cn-hk-eq-01-13,讓台灣大哥大行動網從「可用」升到「第一梯隊」,其他業者沒有變差。106 份報告,改一行。

我對「準確度」的要求就是這樣:每次改,都要說得出改善了哪家業者、有沒有讓別家變差。2026 年 10 月第一次改用市占加權時,是一次更新了六個國家的清單;這次則只有一行。

照顧到更多人:缺什麼樣本,就去找什麼人

清單能照顧到誰,取決於收到誰的報告。分析報告最後一段永遠是「待補樣本」。這次台灣的是:

  • 台灣大寬頻只有 3 條線路,再補 3 條。
  • 中嘉 12% 的市占、11 條線路,沒有任何一個節點能排進它的第一梯隊,最好的也只有大約一半的線路達標。清單怎麼換都救不了,要補新版程式的報告和晚上的時段,看是特定時段或地區的問題,還是整家都這樣。
  • 中華電信南部、花東的樣本很少。

這份清單直接變成招募對象。擴充裡有依國家顯示的公告欄,測速程式也只顯示你所在國家的抽獎;缺樣本的業者,我會發「必中獎邀請碼」,或到論壇點名徵人 (例如 10 月中在 Mobile01 徵台灣大寬頻、大大寬頻、亞太、凱擘的用戶)。

國家也是這樣一個一個補上的。擴充現在有 10 個國家的內建清單 (台灣、新加坡、香港、日本、澳洲、美國、澳門、英國、西班牙、俄羅斯)。其他國家的人一樣可以跑測速,先用短回程替自己建列表;報告收夠了,那個國家就有自己的預設清單。

還沒做好的

  • 中嘉的問題還沒解,上面說了,只能先補樣本。
  • 預估時間的常數 (每筆幾秒、各階段固定幾秒) 是在新加坡實測出來的,還沒用各國回報的實際耗時校正。網路檢查頁上的第一個數字只能當參考,開始測速後會一路修正。
  • 只有 Windows 版。Mac 的人只能用命令列版,而且命令列版不會自動寄回報告。

缺樣本的國家和業者還很多。如果你在中國大陸以外、家裡有 Windows 電腦,歡迎跑一次測速。原始碼在 GitHub。

Comments(0)

No comments yet. Be the first to share your thoughts!

Related notes

“Almost NOBODY knows this: Lag-free Bilibili Secret Setting”
How-to guide2 min

The Secret Setting That Fixes Bilibili Buffering

Bilibili buffering overseas? DNS and VPN tricks are a coin toss, because the real problem is the slow CDN node Bilibili assigns you. Install one extension to lock videos onto the fastest node, plus what to use on Android and TV.

繁體中文 / 廣東話 / 简体中文 / English / 日本語 / 한국어

Notice on top of the Bilibili player saying the CDN was slow and playback switched to a backup node
Tech share14 min

Detecting CDN Failures in a Bilibili Extension and Falling Back to Backup Nodes

How the extension decides a CDN node is really broken: which errors to ignore, how to detect stalls from currentTime and the forward buffer, why it switches once quietly before asking you, and how it avoids bouncing between nodes. Also covers live streams.

繁體中文 / English

Cover: the Network panel domain changes from upos-hz-mirrorakam.akamaized.net to upos-sz-mirror08ct.bilivideo.com, above the four hook points: __playinfo__, the playurl API, .m4s segments and live streams
Tech share13 min

Rewriting Bilibili's Stream CDN on the Fly from a Chrome Extension's MAIN World

Bilibili's stream URLs arrive through SSR __playinfo__, the playurl API, segment requests and the live API. Using bilibili-cdn-switcher's code, this walks through hooking each path, what gets rewritten, and the traps: one-shot Response bodies, read-only XHR responseText, and speed tests that must bypass your own hooks.

繁體中文 / English

The same 4K video before and after the extension: buffering at 9 KB/s before, 8.8 MB/s after
Tech share11 min

How to Actually Fix Bilibili Buffering for Good

Why popular Bilibili videos play fine overseas while unpopular ones stall: CDN caching and trips back to origin, why the narrowest link sets your speed, why DNS and VPN tricks are hit or miss, and how my extension picks a default node from real tests across 14 Taiwanese ISPs.

繁體中文 / English

CDNSpeedTest while the speed test is running
How-to guide6 min

How to Join the Bilibili CDN Speed Test

Step-by-step guide: download CDNSpeedTest.exe, pass the network check, log in with a QR code, and send the report so the extension can find the fastest Bilibili servers in your country.

繁體中文 / 简体中文 / English / 日本語 / 한국어

Cover: one page, two JS worlds. typeof chrome.storage is undefined in the MAIN world console and object in the ISOLATED world; both share the DOM and localStorage and talk via postMessage
Tech share14 min

Chrome Extensions: The Basics of MAIN World and ISOLATED World

Patched window.fetch in a content script and the page ignored you? What the MAIN and ISOLATED worlds can each see, the three ways to pick a world, when to split into two scripts, how they talk through localStorage and postMessage, and which forged messages to reject.

繁體中文 / English

Cover: one src/ folder goes through build.mjs into Chrome, Edge and Firefox zips (Chrome and Edge share one sha256), while Safari goes through an Xcode project to the App Store
Tech share19 min

Shipping a Bilibili Extension from One Codebase to Chrome, Edge, Firefox and Safari

How one src/ becomes four store builds, why the zips must be reproducible (with real sha256 runs and a line-ending gotcha), 5-language release notes guarded by a pre-push hook, and which release steps are scripted versus always done by hand.

繁體中文 / English

Dark monitoring panels comparing memory over time: before, usage climbs to the limit and the job dies with OOM and exit 1; after, batches are loaded and released below the limit and finish before the time limit
Tech share5 min

Large-Scale Billing Statement Duplicate-Check Monitor Optimization

Turning a duplicate-rule check over 100K+ billing records from timeouts and OOMs into a daily monitor that reliably finishes within its time and memory limits.

繁體中文 / English