CRC 賽伯格韌性實驗室的最新訊息、活動與媒體報導 https://crcolab.art/ 2026-08-30T00:00:00+08:00 https://crcolab.art/records/2026-08-30-greyzone-forum-slides/ 2026-08-30T00:00:00+08:00

「簡報下載」彭宬代表 CRC 賽伯格韌性實驗室，於台灣民主實驗室、沃草與 CRC 合辦的「Action! 灰色地帶生存指南：資訊戰解析 ✕ 斷網通訊論壇」擔任講者，分享關鍵通訊受阻時的離線工具與實用備案，簡報《斷網防災包》開放下載。

<p>彭宬代表 <a href="/">CRC 賽伯格韌性實驗室</a>，於「Action! 灰色地帶生存指南：資訊戰解析 ✕ 斷網通訊論壇」擔任講者。論壇由台灣民主實驗室主辦。</p> <p><strong>簡報下載</strong></p> <ul> <li>彭宬《斷網防災包》：<a href="https://drive.google.com/file/d/1RtH03YMiR1zPndD-mCebYJMf6FQiR8hb/view?usp=drive_link">https://drive.google.com/file/d/1RtH03YMiR1zPndD-mCebYJMf6FQiR8hb/view?usp=drive_link</a></li> </ul> <p><strong>活動介紹</strong></p> <p>【Action! 灰色地帶生存指南：資訊戰解析 ✕ 斷網通訊論壇】</p> <p>台灣民主實驗室 ✕ 沃草 ✕ CRC賽伯格韌性實驗室</p> <p>🚨 什麼是「灰色地帶（Grey-Zone）作戰」？</p> <p>很多人以為戰爭的開始，一定是飛彈落地與防空警報狂響。但在現代混合戰爭中，對手最常使用的是手段更隱形、難防備的灰色地帶作戰，其中包含海纜中斷、網駭竊資、認知操弄等。</p> <p>讓你我在不知不覺中對現況感到疲倦與無力，陷入習得性無助。</p> <p>它真正的目的，是「在不引發全面軍事衝突的前提下，逐漸改變戰略現狀，一步步瓦解台灣內部的抵抗意志」。</p> <p>▍參加這場論壇，你將會學到：</p> <p>．看破威脅： 拆解 2026 年最新型網路灰色作戰手法。</p> <p>．心智防禦： 面對資訊戰與情緒操弄，建立個人的心智防線，拒絕非黑即白的極端敘事。</p> <p>．斷網備案： 30 分鐘降速演練實測分析！盤點關鍵通訊受阻時的離線工具與實用備案。</p> <p>．互動體驗： 親身體驗青年創作者的知識轉譯作品，讓防災意識自然融入生活。</p> Cyborg Resilience Co-lab https://crcolab.art/ideas/2026-07-28-30-minute-network-survival-guide/ 2026-07-28T00:00:00+08:00

8 月 10 日（中部）與 8 月 13 日（北部）下午 2 時 30 分起，行動網路降速 30 分鐘。這份指南用 3 個設定、3 張截圖、3 句約定完成準備，並附上 14:20 的收尾清單與這半小時該做、別做的事。

<p>3 個設定、3 張截圖、3 句約定，就能順利度過本次演習，這只是行動網路降速，還是可以打電話、傳簡訊！</p> <p>※ 實際演習日期、時間、內容請以政府機關公布為準 ※</p> <p><img src="/assets/2026-JUL-28-30-minute-network-survival-guide-2.jpg" alt="黏土風格圖卡，標題「不是斷網，是降速」。上方台灣地圖上插著兩張標籤：「中部 8/10 週一」與「北部 8/13 週四」，旁邊的鬧鐘與文字寫著「下午 2:30 - 3:00 各 30 分鐘」。左下角「會變慢／手機 4G／5G・手機熱點」配上爬在手機上的蝸牛與轉圈圈的筆電；右下角「全部正常／通話・簡訊・市話・固網 Wi-Fi」配上市話、訊息泡泡、信封與笑臉分享器。" /></p> <p>先確認演習時間和地點，各三十分鐘</p> <p>在演習開始時，用手機 4G／5G 上網，熱點分享給筆電、平板，網速超級慢</p> <p>打電話、傳簡訊、災防告警、110／119：全部正常</p> <p>※ 實際演習日期、時間、內容請以政府機關公布為準 ※</p> <p><img src="/assets/2026-JUL-28-30-minute-network-survival-guide-3.jpg" alt="黏土風格圖卡，標題「調 3 個設定」，三層架子由上而下擺著：1 離線地圖（地圖 App → 頭像 → 離線地圖），一支手機上攤開紙地圖與定位圖釘；2 檔案設離線（手機 App 也要做一次），一朵雲垂下三張文件標籤到手機上打勾；3 影音先下載（開飛航模式測一次），手機顯示飛機圖示，旁邊放著耳機與音符。左下角一名戴眼鏡的黏土人比讚。" /></p> <h2 id="調-3-個設定">調 3 個設定</h2> <p>都是手機／電腦內建的免費功能，動動手指就能用。</p> <p><strong>1. 設定離線地圖</strong> Google 地圖 → 點右上角頭像 → 「離線地圖」→ 「選取自己的地圖」→ 把住處周遭、公司一帶等比經之處都下載起來。</p> <p><strong>2. 設定雲端離線版檔案</strong> 當天下午要用的簡報、報價單、合約 PDF，在 Google 雲端硬碟／OneDrive／Dropbox 等雲端硬碟上點右鍵，選「可離線存取」或「一律保留在此裝置」。<strong>手機版 App 也要各做一次</strong>。</p> <p><strong>3. 把音樂和影片存下來</strong> 把通勤要聽的 Podcast / 音樂 / 影片先下載。</p> <p>存完之後記得把所有 WiFi 關掉 + 打開飛航模式，測試這些離線檔案真的能用。</p> <p><img src="/assets/2026-JUL-28-30-minute-network-survival-guide-4.jpg" alt="黏土風格軟木板圖卡，標題「截 3 種截圖」，三列分別是：1 電話號碼／你有他的通訊軟體，沒有他的號碼，旁邊是聯絡人清單、紙條與兩個打叉的訊息泡泡；2 當天行程／會議時間・地點・對方電話，旁邊是月曆、名片與時鐘；3 票券與地址／訂位代號・活動 QR・附近避難處所，旁邊是車票、QR 碼與避難處所標誌。右下角一名戴眼鏡的黏土人舉著手機拍照。" /></p> <h2 id="截-3-種截圖">截 3 種截圖</h2> <p>存進相簿就好，不需網路也能看。</p> <p><strong>1. 電話號碼</strong> 家人、學校／安親班、主管、當天要聯絡的客戶。 <strong>很多人只有對方的 LINE，根本不知道手機號碼。</strong> 記得順手抄一份紙條放皮夾，手機沒電也還在。</p> <p><strong>2. 當天行程</strong> 會議時間、地點、對方姓名、電話號碼。</p> <p><strong>3. 票券與地址</strong> 高鐵及台鐵已付款的「訂位代號（碼）」截圖後，持訂位人證件領紙本票；活動 QR 碼、要拜訪的地址門牌，以及住家／公司附近的避難處所（可查內政部警政署防空避難專區，或是先下載「警政服務 App」、存下「消防防災 e 點通 App」中的「離線地圖」）。</p> <p>註一：高鐵及台鐵公司皆明文禁止使用截圖車票 QR 碼。</p> <p>註二：活動 QR 碼截圖使用規定請以各單位/公司之規定條款為準。</p> <p><img src="/assets/2026-JUL-28-30-minute-network-survival-guide-5.jpg" alt="黏土風格格子櫃圖卡，標題「講 3 句約定」：1 對家人／傳不出去是演習，不是出事，畫面是辦公桌前的上班族與家中泡茶的長輩各自拿著市內電話，話筒線相連；2 對同事／這半小時不排線上會議，一隻手把 14:30 的會議方塊沿箭頭往下挪到 15:30 之後；3 對接送的人／打不通就去說好的地方等，媽媽在校門口向揹書包的孩子揮手。" /></p> <h2 id="進行-3-種約定">進行 3 種約定</h2> <p>不花一毛錢，只要開口講。</p> <p><strong>1. 對家人、長輩、朋友</strong> 「8/13 下午 2 點半到 3 點，LINE 可能傳不出去，那是網路降速演習。有事我直接打電話給你，你也可以傳簡訊給我。」 → 這句能省掉對方一整個下午的焦慮～</p> <p><strong>2. 對同事</strong> 「這半小時不排線上會議。」把 14:30 的視訊往前挪到 14:00，或往後挪到 15:10；真的非開不可，就改成純語音電話或走過去面對面講。</p> <p><strong>3. 對外勤同事、接送小孩的人</strong> 講好「回報時間點 ＋ 集合地點」，例如「15:00 我打給你；如果打不通，就在一樓大廳等我」。 <strong>只要在約定好的時間聯絡不上，就改往事先說好的固定會合點。</strong></p> <p><img src="/assets/2026-JUL-28-30-minute-network-survival-guide-6.jpg" alt="黏土風格圖卡，標題「14:20 三分鐘收尾」，副標「送出待辦・先登入好系統・帶現金和實體卡」。畫面上放著一只攤開的皮夾，裡面有千元鈔、兩張卡片與 50 元、10 元硬幣；中間的鬧鐘指著 2 點 20 分；右邊是連著 Wi-Fi 的筆電，前方有一架紙飛機與一封打開的信。" /></p> <h2 id="當天-14203-分鐘收尾">當天 14:20，3 分鐘收尾</h2> <ul> <li> <p>用手機送出的簽核、報表、附件，14:25 前按下送出，不要趕死線。</p> </li> <li> <p>假如公司系統、VPN、網銀<strong>需要用手機 App 推播驗證，先在電腦上登入好，那半小時不要登出</strong>（用簡訊驗證碼的系統則不受影響）</p> </li> <li> <p>需要下單、轉帳、上傳標案的，改用固網電腦處理，或乾脆避開這半小時</p> </li> <li> <p>皮夾檢查：<strong>現金 ＋ 實體悠遊卡／一卡通 ＋ 實體信用卡</strong>。在網速很慢的情況下，可能打不開行動支付 App 的付款條碼。</p> </li> <li> <p>確認筆電連的是辦公室 Wi-Fi，而不是自己的手機熱點</p> </li> </ul> <p><img src="/assets/2026-JUL-28-30-minute-network-survival-guide-7.jpg" alt="黏土風格左右對比圖卡，標題「這半小時，這樣過」。左邊綠色打勾「打電話・做離線的事・面對面講」，一名戴眼鏡的人在檯燈下拿鉛筆校對成疊紙本，手機安靜放在桌上；右邊橘色打叉「別狂重整・別改網路設定」，另一個人冒著冷汗皺眉猛戳手機，桌上擺著路由器。" /></p> <h2 id="14301500這-30-分鐘怎麼過">14:30–15:00：這 30 分鐘怎麼過</h2> <p><strong>可以做的</strong></p> <ul> <li> <p>連辦公室或家裡的固網 Wi-Fi，大致無感</p> </li> <li> <p>要找人就打電話；不急就傳簡訊</p> </li> <li> <p>把它排成一段「離線工作時段」：紙本校對、寫文件、整理桌面、走過去把事情跟同事講完</p> </li> </ul> <p><strong>別做的</strong></p> <ul> <li> <p>別狂點重新整理。越多人重試，體感越慢</p> </li> <li> <p>別去改網路設定或 APN，事後很容易忘記怎麼改回來</p> </li> <li> <p>別急著打電信客服</p> </li> </ul> <p><img src="/assets/2026-JUL-28-30-minute-network-survival-guide-8.jpg" alt="黏土風格圖卡，文字寫著「3 點演習結束後⋯」「行動網路沒恢復？重新開機」「記下最卡的那件事，跟親友討論未來備案」「因為真正的天災斷網，不會提前公告時間」。畫面右側是一名戴眼鏡的黏土人在書桌前用鉛筆寫筆記，桌上有筆筒、盆栽與立著的手機，牆上時鐘指著 3 點。" /></p> <h2 id="1500-之後">15:00 之後</h2> <p>網路沒有自動恢復的話：<strong>開飛航模式 10 秒再關掉</strong>，或直接重新開機。</p> <p>然後花兩分鐘問自己一句：<strong>剛剛最卡的是哪一件事？</strong> 是找不到某個人的電話、付不了款、還是打不開一份檔案？把它記下來，因為網路假如因為真正的颱風、地震受損時，不會有人提前公告時間。</p> <p>延伸閱讀：<a href="/ideas/2026-07-22-mobile-network-throttling-drill/">為什麼要進行「行動網路降速」演習？有意義嗎？</a></p> <p>※ 實際演習日期、時間、內容請以政府機關公布為準 ※</p> Cyborg Resilience Co-lab https://crcolab.art/ideas/2026-07-22-mobile-network-throttling-drill/ 2026-07-22T00:00:00+08:00

2026 城鎮韌性演習首度納入「行動網路降速」：8 月 10 日與 8 月 13 日下午 2 時 30 分起降速 30 分鐘。從花蓮強震、丹娜絲颱風的基地台受損，到日、韓、北約與芬蘭的通訊演練，談把斷網情境納入防災演習的意義。

<p>台灣的行動網路資費、連線速度與連線品質在全球名列前茅，這有賴三大電信業者與政府長期的建設維運，民眾才能享受穩定又便宜的行動網路環境。</p> <p>不過，台灣同時也是颱風、地震頻發的國家。天災除了破壞供水與電網，也會波及基地台與纜線等網通設備：2024 年 4 月 3 日規模 7.2 的花蓮強震，尖峰時曾造成 172 座行動基地台受影響（多集中於宜花地區）[1]；2025 年 7 月丹娜絲颱風更使嘉南地區一帶逾 1,300 座基地台因斷電或毀損而停止服務[2][3]，部分基地台直到同年 10 月底才全數修復[4]。行動網路中斷不僅讓災區居民難以聯繫親友，更阻礙救災調度。</p> <p>值得注意的是，基地台受損多造成「局部斷網」，而當對外海纜受損時，恐會出現「全島降速」：許多日常使用的 app 與網站，核心伺服器都在海外，一旦國際頻寬驟減，即使島內網路正常，服務仍會嚴重卡頓。賽伯格韌性實驗室 CRC 今年 3 月 25 日舉辦的<a href="/ideas/2026-03-25-crc-march-25-decks/">「數位韌性論壇：地緣政治下的海纜與網路基礎設施」</a>，即針對這類網路部分受損情境進行模擬分析[5]，當時的結論之一，就是「無論政府或民間的演練皆需納入網路受損情境」。</p> <p>政府長期推動防救災教育與避難演練，讓民眾在天災來臨前熟悉應變流程，培養處理突發狀況的能力。減（防）災的核心是盡可能降低天災對生活的衝擊；隨著常民生活愈發依賴網路，「網路降速或中斷」也應納入演練情境。</p> <p>這類與網路、通訊有關的演練在國際上並非首創：日本總務省與電信機構組成的「非常通信協議會」（日文：非常通信協議会），定期演練公眾線路與防災無線中斷時，會以備用電源與替代通訊線路傳遞災情的「非常通信訓練」[6]；韓國 2025 年「乙支演習」（을지연습）動員約 4,000 個機關、58 萬人，情境除了通訊中斷、網路基礎設施破壞外，更涵蓋 GPS 遭干擾情境[7]；北約的網路防禦卓越中心（CCDCOE）每年於愛沙尼亞塔林舉辦全球規模最大的實戰網路防禦演習 Locked Shields，動員 41 國、逾 4,000 人演練關鍵基礎設施防禦，其中也針對通訊基礎設施遭破壞的情境進行演練[8]。</p> <p>芬蘭甚至連續九年由數位暨人口資料服務局（DVV）每年舉辦全國性「TAISTO」網路及資安演習，免費開放所有公部門組織參加，近年單屆逾 450 個機關機構參與，與警方和國安機構合作，針對網路攻擊、系統遭駭、甚至是 AI 資安等情境進行模擬[9]。</p> <p>今年的城鎮韌性演習首度納入「行動網路降速」演練：8 月 10 日（中部 7 縣市）與 8 月 13 日（北部 7 縣市）下午 2 時 30 分起，模擬啟動災害漫遊與分級限流後頻寬不足的情境，降速 30 分鐘；語音通話、簡訊、災防細胞簡訊與 110、119 等緊急電話均不受影響，以寬頻固網運作的 Wi-Fi 也不受影響[10]。民眾可藉此練習離線地圖、現金支付、手機號碼聯繫等替代方案，為可能出現的天災預作準備。</p> <p>我們樂見本年度演習新增此項目，也期待未來的演習及防災教育持續擴大並深化數位韌性相關情境！</p> <p>距離演習還有半個月，CRC 在下週將分享如何為「行動網路降速」演習做準備，歡迎厲害的大家在留言分享自己或親友已經為這次演習做了哪些安排～～</p> <h2 id="參考資料">參考資料</h2> <ol> <li>中央社，〈<a href="https://www.cna.com.tw/news/ahel/202404030090.aspx">強震影響三大電信172個基地台 NCC：估今天可修復</a>〉，2024/4/3。</li> <li>行政院，〈<a href="https://www.ey.gov.tw/Page/448DE008087A1971/d6215b19-fc53-4373-989b-80ef81bf8277">丹娜絲颱風應變處置與復原情形</a>〉（統計至 2025/7/9，基地臺受損 1,360 座）。</li> <li>聯合新聞網，〈<a href="https://udn.com/news/story/7326/8925595">丹娜絲風災重創嘉南通訊避免數位孤島 NCC啟動災害漫遊</a>〉（南部 1,293 座基地台因斷電或毀損）。</li> <li>中央社，〈<a href="https://www.cna.com.tw/news/afe/202508040028.aspx">颱風丹娜絲重創基地台 中華電信：預定10月底前復原</a>〉，2025/8/4。</li> <li>CRC 賽伯格韌性實驗室，<a href="/ideas/2026-03-25-crc-march-25-decks/">「數位韌性論壇：地緣政治下的海纜與網路基礎設施」</a>，2026/3/25。</li> <li>非常通信協議会，《<a href="https://www.bousai.go.jp/kaigirep/houkokusho/hukkousesaku/saigaitaiou/output_html_1/pdf/4.pdf">非常通信確保のためのガイド・マニュアル</a>》。</li> <li>이치저널，〈<a href="https://www.eachj.co.kr/news/articleView.html?idxno=13386">“드론과 GPS가 멈춘다”… 전 국민이 훈련에 들어가는 3박 4일, 2025 을지연습</a>〉，2025/8。</li> <li>NATO CCDCOE, “<a href="https://ccdcoe.org/locked-shields/">Locked Shields</a>“。</li> <li>Digi- ja väestötietovirasto（DVV），”<a href="https://dvv.fi/taisto">TAISTO-harjoitus</a>“；另見 <a href="https://dvv.fi/-/tanaan-kaynnistyva-taisto-harjoitus-kokoaa-yli-330-organisaatiota-harjoittelemaan-ajankohtaisten-digiuhkien-varalle">DVV 新聞稿</a>。</li> <li>中央社，〈<a href="https://www.cna.com.tw/news/aipl/202607210026.aspx">城鎮韌性演習14縣市手機降速非斷網 影響範圍一篇看懂</a>〉，2026/7/21。</li> </ol> Cyborg Resilience Co-lab https://crcolab.art/events/2026-07-19-mesh-newbies-workshop/ 2026-07-19T00:00:00+08:00

從零開始介紹 Meshtastic 的運作方式、硬體設備選擇、軟體安裝與基本設定。歡迎第一次接觸 Meshtastic 的初學者，帶著自有的裝置一起參與；若無裝置者，現場會有少量裝置可以玩玩看。

<p>是否常聽到人說：「網路斷線後可以用那個 Mesh 啊！」如果有聽過，表示你有在關注「斷網後怎麼通訊」的議題；如果沒聽過，但很在意「如果斷網怎麼辦？」那這也是一個開始了解的機會。</p> <p><strong>Mesh 是什麼？</strong></p> <p>Mesh 本意是網，常用來指網狀結構的網路和通訊，也就是不完全依賴單一集中的發送點（如電信基地台），而是透過多台設備彼此連結，形成可以互相傳遞訊息的網路。</p> <p><strong>Meshtastic 是什麼？</strong></p> <p>這是網狀網路的其中一套技術系統，也是台灣民間常討論的離網通訊方案，並有相當活動的社群在搭建和交流技術。Meshtastic 利用 LoRa 無線電技術，在不依賴行動網路、Wi-Fi 或網際網路的情況下，讓裝置之間形成分散式的網狀通訊網路。</p> <p>在這場新手工作坊中，我們將從零開始介紹 Meshtastic 的運作方式、硬體設備選擇、軟體安裝與基本設定。歡迎第一次接觸 Meshtastic 的初學者，帶著自有的裝置一起參與。若無裝置者，也可以來聽聽看，現場會有少量裝置給大家玩玩看。</p> <p><strong>活動資訊</strong></p> <ul> <li>時間｜7月19日（日）10:30–12:00</li> <li>地點｜NPO Hub 二樓，Impact Space</li> <li>人數有限，須事先報名（本場報名已截止）</li> </ul> Cyborg Resilience Co-lab https://crcolab.art/records/2026-07-01-cna-lee-tzutung-sweden/ 2026-07-01T00:00:00+08:00

CRC 藝術家李紫彤日前於瑞典展出個展《Mercy and Vengeance in the Bardo》，透過作品與工作坊，思考從性別暴力到後人類戰爭的各種暴力形式。《姑娘廟的無人機藝》延續 CRC 對後人類戰爭、無人機與科技政治的共同探索。

<p>謝謝中央社的報導！</p> <p>CRC 藝術家 #李紫彤 日前於瑞典展出個展《中陰裡的慈悲與復仇》（Mercy and Vengeance in the Bardo），並透過作品與工作坊，思考從性別暴力到後人類戰爭的各種暴力形式，以及人們如何在其中尋找療癒與抵抗的可能。</p> <p>其中，《姑娘廟的無人機藝》（The Temple of the Wandering Daughter）延續了我們在 CRC 對後人類戰爭、無人機與科技政治的共同探索。當戰爭變得既「遠端」又「日常」、當機器、演算法、基礎設施都日漸武器化，我們要如何重新建立關係、記憶與抵抗。</p> Cyborg Resilience Co-lab https://crcolab.art/news/2026-06-29-c-lab-residency/ 2026-06-29T00:00:00+08:00

CRC 進駐臺灣當代文化實驗場 C-LAB，由藝術家與策展人李紫彤推動，將以藝術與手作方式邀請大家理解台灣「薛丁格」的備戰狀態。下半年將舉辦 2 場公開講座與 1 場年末展演。

<p>上週在《在廢土之濱練習存活》之後，我們以跨界藝術科技，進駐臺灣當代文化實驗場 C-LAB 啦。</p> <p>第一線的台灣人，早就沉浸式體驗現代灰色戰爭，在一個個 AI 帳號、一次次共機擾台、一場場兵推活動、一本本避難手冊中，讓一些人焦慮過敏、另外一些人不知從何在意起。</p> <p>在團隊藝術家與策展人 #李紫彤 推動下，除了網路、韌性等數位通訊硬技術，CRC 也邀請大家一起用藝術和手作等方式，理解這「薛丁格」的備戰狀態、感受一言難盡的台灣日常。</p> <p><strong>下半年活動預告</strong></p> <ul> <li>2 場公開講座</li> <li>1 場年末展演</li> </ul> <p>活動詳情將陸續公布，敬請關注 CRC 的最新訊息。</p> Cyborg Resilience Co-lab https://crcolab.art/events/2026-06-27-wilderness-survival-talk/ 2026-06-27T00:00:00+08:00

台灣是個多災多難的島嶼，人人自危，卻也人人自訓。本場講座從民間戍衛、數位韌性與基層醫療切入，討論非傳統編制下的新型態組織者，如何在高風險環境中生成能動性。

<p><strong>時間</strong>｜6月27日（六）14:00–16:00 <strong>地點</strong>｜共享吧</p> <p>台灣是個多災多難的島嶼，人人自危，卻也人人自訓。從民間戍衛、數位韌性與基層醫療切入，本場講座討論非傳統編制下的新型態組織者，如何在高風險環境中生成能動性，以及如何把危機感轉化為訓練、知識與互助網絡。</p> <p><strong>講者</strong></p> <ul> <li>前線民主計畫｜劉以正（ARTICLE 19 亞太專員）</li> <li>賽伯格韌性實驗室 CRC｜Lulu Keng</li> <li>地頭蛇計畫｜陳德叡</li> </ul> <p><strong>轉譯</strong></p> <ul> <li>RC 基金會執行長、Podcast 人間動物園插話家、實現會社社長｜王俊凱</li> </ul> Cyborg Resilience Co-lab https://crcolab.art/records/2026-06-15-rti-meshtastic/ 2026-06-15T00:00:00+08:00

「荊輔翔表示，社群初期僅有約 50 位成員，如今已達近 2 萬人，遍佈台北、台中、高雄、花蓮等全台各地，估計有超過 1,000 台裝置正在運作。」CRC @ g0v summit 2026 數位韌性軌議程之一的深度報導。

<p>特別感謝 Rti 中央廣播電臺報導！</p> <blockquote> <p>「荊輔翔表示，社群初期僅有約 50 位成員，如今已達近 2 萬人，遍佈台北、台中、高雄、花蓮等全台各地，估計有超過 1,000 台裝置正在運作……隨著越來越多民眾自行建置系統、全台覆蓋率約八成，目前大部分居住地都能使用 Meshtastic 進行通訊。」</p> </blockquote> <p>聽起來用 Mesh 通訊，是不是比去拔電輔車電池可行一點？</p> <p>不過彈來彈去的無線電波，該怎麼適用牆壁跟干擾都超多的都市，和相反的鄉村、山地呢？</p> <p><strong>CRC @ g0v summit 2026 數位韌性軌議程之一，以下摘錄標題捕捉報導重點：</strong></p> <ul> <li>Meshtastic：一千元、一個下午就能自建離線版 LINE</li> <li>臺灣鏈網 Meshtastic 社群覆蓋率已達 80%</li> <li>Meshtastic 真是好的通訊替代方案嗎？</li> <li>一般人需要準備 Meshtastic 嗎？</li> </ul> Cyborg Resilience Co-lab https://crcolab.art/records/2026-06-08-rti-blackout-resilience/ 2026-06-08T00:00:00+08:00

「當電網中斷導致電信基地台停擺，家中又如何供電給 Wi-Fi 路由器？路由器電壓通常只需要 10 至 28 伏特之間，所以車用電池模組即為緊急時刻相當便利且容易取得的電力來源。」CRC @ g0v summit 2026 數位韌性軌議程之一。

<p>特別感謝 Rti 中央廣播電臺報導！</p> <blockquote> <p>「不過當電網中斷導致電信基地台停擺，家中又如何供電給 Wi-Fi 路由器？Michael 說明，路由器電壓通常只需要 10 至 28 伏特之間，所以如電動車電池等車用電池模組即為緊急時刻相當便利且容易取得的電力來源，可確保內部通訊網絡的健全運作。」</p> </blockquote> <p>BUT、但是、しかし，以上情境只是緊急事態的模擬，手先別伸向附近的電動車電池站，小心觸法 🔋</p> <p><strong>CRC @ g0v summit 2026 數位韌性軌議程之一，以下摘錄標題捕捉報導重點：</strong></p> <ul> <li>面對斷網危機 烏克蘭與緬甸的實戰經驗</li> <li>當海纜全斷 即便資料中心在台灣 LINE 恐也不通</li> <li>烏克蘭：打造境內通訊網絡 FB、LINE 都有替代方案</li> <li>PTT 能成台灣版 dComms 嗎？</li> <li>沒電怎麼辦？你家路口的 Gogoro 電池</li> <li>在危機來臨前 要準備什麼？</li> </ul> Cyborg Resilience Co-lab https://crcolab.art/records/2026-05-24-offline-mission-recap/ 2026-05-24T00:00:00+08:00

超過 180 人次、接力 67 分鐘、總長 9.2 km 的飛輪發電，把韌性訊息源源不絕送進 meshbridge 留言版。Reticulum 機器人在兩天內互傳了 6759 條訊息，訊息量之大，開始讓人懷疑它們是不是偷偷發展出自己的社交圈。

<p>感謝參與「離線行動」的沒有人們！</p> <p>超過 <strong>180 人次</strong>、接力 <strong>67 分鐘</strong>、總長 <strong>9.2 km</strong> 的飛輪發電，把韌性訊息源源不絕送進 meshbridge 留言版。現場還有數十位參與者成功用 Wi-Fi 連上留言版。而 Reticulum 機器人更在兩天內互傳了 <strong>6759 條訊息</strong>，訊息量之大，已經開始讓人懷疑它們是不是偷偷發展出自己的社交圈！？</p> <p>CRC 在此正式宣佈：本次離線行動，任務成功！</p> <p><img src="/assets/2026-MAY-24-offline-mission-2.jpg" alt="離線行動現場" /></p> <p><img src="/assets/2026-MAY-24-offline-mission-4.jpg" alt="離線行動現場" /></p> <p><img src="/assets/2026-MAY-24-offline-mission-5.jpg" alt="離線行動現場" /></p> <p>更多後續分享，敬請關注我們。CRC 持續發電傳訊中⚡</p> <p>感謝 #g0vsummit2026 與 OpenFun 的協力。</p> Cyborg Resilience Co-lab https://crcolab.art/records/2026-05-24-g0v-summit-panel-slides/ 2026-05-24T00:00:00+08:00

「簡報連結」數位韌性系列活動 (at) g0v Summit 2026

<p>數位韌性系列活動 (at) g0v Summit 2026 的簡報連結：</p> <p><strong>數位生命線：關於網路海纜你該知道的一切 Digital Lifeline: Everything You Need to Know About Subsea Cables</strong></p> <ul> <li>周詳 Sean Chou: <a href="https://docs.google.com/presentation/d/1Pj9pSy5K9w1ehX5dsC7cOoDFwmkwbCS2cEdn2K981sc/edit">https://docs.google.com/presentation/d/1Pj9pSy5K9w1ehX5dsC7cOoDFwmkwbCS2cEdn2K981sc/edit</a> (All rights reserved)</li> <li>唐若凌 Athena Tong: <a href="https://drive.google.com/file/d/1X0F9t83NNC7mw5-82mB0jen2mLDl2EdU/view">https://drive.google.com/file/d/1X0F9t83NNC7mw5-82mB0jen2mLDl2EdU/view</a> (All rights reserved)</li> <li>彭宬 CHENG PENG: <a href="https://paulpengtw.github.io/crccolab-implications-of-internet-traffics-drop-to-50-percent-and-what-to-do/">https://paulpengtw.github.io/crccolab-implications-of-internet-traffics-drop-to-50-percent-and-what-to-do/</a> (Licsense: CC BY-SA 4.0)</li> </ul> <p><strong>斷網之後：打造烏克蘭、緬甸與台灣的通訊韌性網絡 After the Blackout: Off-the-grid Communication Solutions in Ukraine, Myanmar and Taiwan</strong></p> <ul> <li>Sean Ching: <a href="https://docs.google.com/presentation/d/1OhzajvjjwuUDTEJsLs23il_z6JHUp86_YGE6GeM3hGY/edit">https://docs.google.com/presentation/d/1OhzajvjjwuUDTEJsLs23il_z6JHUp86_YGE6GeM3hGY/edit</a> (Licsense: Beerware)</li> <li>Aidan: <a href="https://drive.google.com/file/d/1Kf45_w129YS3GOH7H_hPnFn-o1cOOsyC/view">https://drive.google.com/file/d/1Kf45_w129YS3GOH7H_hPnFn-o1cOOsyC/view</a></li> <li>Michael Suantak: <a href="https://drive.google.com/file/d/1GSPfOFlLUVFZg3a49uUmzgSovpkLntdc/view">https://drive.google.com/file/d/1GSPfOFlLUVFZg3a49uUmzgSovpkLntdc/view</a></li> </ul> Cyborg Resilience Co-lab https://crcolab.art/events/2026-05-23-hackathon-2026/ 2026-05-23T00:00:00+08:00

5月23日暖身行動、5月24日一日黑客松。三場主題座談 + Off-the-grid 通訊突圍挑戰賽。烏克蘭（dComms）、緬甸（ASORCOM）與台灣實作者齊聚，探討斷網情境下的通訊韌性。

<p>CRC 與歐噴有限公司（OpenFun Inc.）共同主辦的兩日活動：5月23日（六）暖身行動、5月24日（日）一日黑客松，地點在中央研究院人文社會科學館。</p> <p>三場主題座談，「數位生命線：關於網路海纜你該知道的一切」、「斷網之後：打造烏克蘭、緬甸與台灣的通訊韌性網絡」、「數位韌性實驗室：Off-the-Grid Network 技術交流」，加上橫跨整棟人文館的場邊通訊突圍挑戰賽（Meshtastic 留言板、Reticulum 跨媒介傳輸、飛鴿傳書）。</p> <p>完整議程與活動紀錄請見活動頁：<a href="/events/hackathon-2026/">數位韌性國際黑客松 2026</a></p> Cyborg Resilience Co-lab https://crcolab.art/records/2026-05-06-panel-invited-by-rsf/ 2026-05-06T00:00:00+08:00

「簡報連結」無國界記者邀請分享海纜議題與 Meshtastic 社群

<p>Thanks to Reporters Without Borders (RSF) for inviting us to share about the undersea cable issue and the Meshtastic Taiwan community, the following are the slide decks of the presentation:</p> <ul> <li>CHENG PENG’s Slide Decks: <a href="https://paulpengtw.github.io/crccolab-May-6-2026-why-cable-cuts-matters/">https://paulpengtw.github.io/crccolab-May-6-2026-why-cable-cuts-matters/</a> (Licsense: CC BY-SA 4.0)</li> <li>Sean Ching’s Slide Decks: <a href="https://docs.google.com/presentation/d/12XXii10OHNy3xO8sI9PzjoscqG5FojyzFT7FaBgDScc/edit">https://docs.google.com/presentation/d/12XXii10OHNy3xO8sI9PzjoscqG5FojyzFT7FaBgDScc/edit</a> (Licsense: Beerware)</li> </ul> Cyborg Resilience Co-lab https://crcolab.art/records/2026-03-27-rti-forum-coverage/ 2026-05-02T00:00:00+08:00

5 月 23 日暖身行動、5 月 24 日一日黑客松。三場主題座談 + Off-the-grid 通訊突圍挑戰賽，中央研究院人文社會科學館。烏克蘭、緬甸與台灣實作者齊聚，探討斷網情境下的通訊韌性。

<p>連結網路的海底纜線，近期成為熱門焦點。被海圍繞的台灣，對於海纜的各種變化更是格外敏感、易受影響，在不穩定的地緣政治下更顯脆弱。當網路真的消失，我們還能把訊息傳出去嗎？</p> <p>CRC 與歐噴有限公司（OpenFun Inc.）共同主辦這場兩日活動，邀請來自烏克蘭（dComms）、緬甸（ASORCOM）與台灣的實作者，分享在戰區、叢林與離島偏鄉裡，如何用 Meshtastic、Reticulum、聯邦式協定、本地伺服器等替代方案建立 off-the-grid 通訊韌性。</p> <p>日期：5 月 23 日（六）暖身行動 · 5 月 24 日（日）一日黑客松 地點：中央研究院 人文社會科學館（台北南港） 形式：主題講座 · 圓桌交流 · 場邊通訊挑戰賽</p> <p>【座談場次｜5 月 24 日（日）】</p> <ul> <li>數位生命線：關於網路海纜你該知道的一切（10:30–12:00）</li> <li>斷網之後：打造烏克蘭、緬甸與台灣的通訊韌性網絡（13:00–14:30）</li> <li>數位韌性實驗室：Off-the-Grid Network 技術交流（15:30–16:30）</li> </ul> <p>【場邊挑戰賽｜5 月 23 日（六）及 5 月 24 日（日）】</p> <p>橫跨整棟人文館的通訊突圍任務，操作 Meshtastic 留言板、Reticulum 跨媒介傳輸、「飛鴿傳書」，一關一關突破限制！</p> <p>活動詳情：<a href="/events/hackathon-2026/">crcolab.art/events/hackathon-2026/</a></p> Cyborg Resilience Co-lab https://crcolab.art/news/2026-05-02-hackathon-2026-upcoming/ 2026-05-02T00:00:00+08:00

5月23日暖身行動、5月24日一日黑客松。三場主題座談 + Off-the-grid 通訊突圍挑戰賽，中央研究院人文社會科學館。烏克蘭、緬甸與台灣實作者齊聚，探討斷網情境下的通訊韌性。

<p>連結網路的海底纜線，近期成為熱門焦點。被海圍繞的台灣，對於海纜的各種變化更是格外敏感、易受影響，在不穩定的地緣政治下更顯脆弱。當網路真的消失，我們還能把訊息傳出去嗎？</p> <p>CRC 與歐噴有限公司（OpenFun Inc.）共同主辦這場兩日活動，邀請來自烏克蘭（dComms）、緬甸（ASORCOM）與台灣的實作者，分享在戰區、叢林與離島偏鄉裡，如何用 Meshtastic、Reticulum、聯邦式協定、本地伺服器等替代方案建立 off-the-grid 通訊韌性。</p> <p>日期：5月23日（六）暖身行動 · 5月24日（日）一日黑客松 地點：中央研究院 人文社會科學館（台北南港） 形式：主題講座 · 圓桌交流 · 場邊通訊挑戰賽</p> <p>【座談場次｜5月24日（日）】</p> <ul> <li>數位生命線：關於網路海纜你該知道的一切（10:30–12:00）</li> <li>斷網之後：打造烏克蘭、緬甸與台灣的通訊韌性網絡（13:00–14:30）</li> <li>數位韌性實驗室：Off-the-Grid Network 技術交流（15:30–16:30）</li> </ul> <p>【場邊挑戰賽｜5月23日（六）及5月24日（日）】</p> <p>橫跨整棟人文館的通訊突圍任務，操作 Meshtastic 留言板、Reticulum 跨媒介傳輸、「飛鴿傳書」，一關一關突破限制！</p> <p>活動詳情：<a href="/events/hackathon-2026/">crcolab.art/events/hackathon-2026/</a></p> Cyborg Resilience Co-lab https://crcolab.art/records/2026-04-20-kuma-academy-mesh-workshop/ 2026-04-20T00:00:00+08:00

黑熊學院整理荊輔翔於 CRC Mesh 工作坊的分享，為什麼需要離網通訊備案、Mesh 在都市與開闊地的通訊距離、台灣社群經驗（MESHTW 頻道、Meshtastic Taiwan Community），以及最新開發的「Meshbridge 留言板」，讓沒有硬體裝置的使用者也能透過 Wi-Fi 連上 Mesh 網絡。

<blockquote> <p>「正是因為太方便，所以網路斷掉的時候，沒有人準備好備用方案。」</p> </blockquote> <p>這是荊輔翔盤點和回顧台灣通訊相關基礎設施下的一個註腳。正是因為有相關單位從業人員努力，近年電信網路沒有大規模斷網超過半天以上的紀錄，若是大城市發生斷網，大致也能在 24 小時內能被解決。可就是因為這樣的便利，使得我們將網路和電力視為空氣一般的理所當然，所以民眾會在斷網的時候產生強烈恐慌。也因此，民間開始研究與討論 Meshtastic，以作為另一個通訊備案。</p> <p><strong>究竟需要多遠的聯繫距離呢？</strong></p> <p>多數人每天花 30 至 60 分鐘通勤，換算成距離差不多是 10 至 30 公里的活動範圍。也就是說，當災害發生、通訊中斷、在搶修完成前的空白期間，大家要的並不是台北至高雄的遠程通訊，而是想知道家人、朋友是否平安這種短時間、小範圍的突發狀況，這正是 Mesh 能發揮其功能的最佳情境。理論上就算在充滿干擾的都市水泥叢林，點對點的通訊能傳到 3 至 5 公里，再透過中繼能力，Mesh 可以輕易覆蓋日常通勤的範圍；開闊地更可大幅提升至 30 公里。</p> <p><strong>台灣社群經驗分享</strong></p> <p>台灣最大的 Mesh 臉書社群「Meshtastic Taiwan Community 臺灣鏈網」，裡面有許多前輩能幫忙回答操作 Mesh 時遇到的各種問題。更重要的是，台灣社群創立了「MESHTW」這個頻道，讓同好們能彼此相互聯絡和測試，目前已在北台灣形成一個穩定的通訊網絡。輔翔也提醒小團隊成員平時就該不定時進行器材測試，在信任的小圈圈建立可信任的通訊網絡和使用規範。</p> <p><strong>最新應用「Meshbridge 留言板」</strong></p> <p>Mesh 的操作仍需要每位使用者都有硬體裝置和手機 APP，但有沒有一種可能是：「一個團體只需要擁有一台裝置，卻能共享使用其網絡並跟外界聯繫」？在這個動機下，輔翔跟同好將 Mesh 結合「樹莓派」完成具有 Wi-Fi 功能的 Meshbridge 專案。即便沒有 Mesh 硬體裝置的使用者也能直接用手機 Wi-Fi 連上 Mesh 通訊網絡，跳轉到 Chrome 頁面進行對話與留言。這對於在社區大樓推廣 Mesh 通訊備援時，大幅降低所需技術和開銷門檻，是一個令人振奮的 Mesh 開發專案。</p> <p><em>（本文由黑熊學院整理撰寫。）</em></p> Cyborg Resilience Co-lab https://crcolab.art/records/2026-04-10-dset-forum-coverage/ 2026-04-10T00:00:00+08:00

DSET 兼任研究員張仁瑋出席 CRC 主辦「數位韌性論壇」，分享烏克蘭戰時資安與通訊維運經驗，全國漫遊、衛星橋接、緊急頻譜、備援供電與持續搶修的組合式應變。Starlink 雖重要，但台灣當務之急是建立多層次、多供應商、可分級調度的國家網路架構。

<!-- date 2026-04-10 is an estimate; the DSET article did not include a publish date. Placed between the 3/25 forum and the 4/20 Kuma article. --> <p>DSET 兼任研究員張仁瑋於 3 月 25 日代表出席由賽伯格韌性實驗室（CRC, Cyborg Resilience Co-lab）主辦、以「地緣政治下海纜與網路基礎設施」為題的「數位韌性論壇」，分享 <strong>#烏克蘭戰時資安與通訊維運</strong> 經驗，並提出對台灣的政策建議。</p> <p>本次「數位韌性論壇」由賽伯格韌性實驗室（CRC）、g0v.tw 台灣零時政府、開放文化基金會等社群共同推動，並由 CRC 共同創辦人李梅君與開放文化基金會執行長李欣穎主持。DSET 於論壇下半場參與討論，與國防安全研究院、數位發展部及民間技術社群代表共同交流數位韌性相關議題。</p> <p>張仁瑋以烏克蘭戰時資安攻擊案例為例指出，數位韌性並非在危機發生後才臨時建立，而是奠基於平時的網路基礎條件與戰時的快速調度能力。他表示，烏克蘭除了具備較多元的網路結構與跨境互連條件，也在戰時透過 <strong>#全國漫遊</strong>、<strong>#衛星橋接</strong>、<strong>#緊急頻譜</strong>、<strong>#備援供電</strong> 與 <strong>#持續搶修</strong> 等措施維持關鍵通訊運作；其中，後者的組合式應變作法尤其值得台灣借鏡。</p> <p>他進一步指出，Starlink 雖然重要，但並非脫離既有基礎條件即可獨立運作的單一解方。對台灣而言，當務之急是建立多層次、多供應商、可分級調度的國家網路架構，並盤點跨業者協調、路由主權與網域治理等風險。</p> <p>尤其在台灣高度依賴海纜對外通訊的情況下，必要流量的優先維持、海外繞路可能造成的服務中斷，以及關鍵控制層能否在境內獨立運作，都是必須及早釐清的核心課題。此外，DNS、BGP 等通訊治理議題也涉及國際協力，台灣與盟友之間的事件通報、鑑識合作與境外備援機制，仍有待進一步制度化與透明化。</p> <p>張仁瑋表示，台灣下一步應以「持續運作」為數位韌性核心，強化關鍵節點備援，並透過跨部門、跨業者的複合式演練，將國際經驗轉化為在地可行方案。</p> <p><em>（本文由 DSET 撰寫整理。）</em></p> Cyborg Resilience Co-lab https://crcolab.art/records/2026-04-01-forum-recap-upper-half/ 2026-04-01T00:00:00+08:00

3/25 數位韌性論壇「Section 1 海纜專題與技術報告」講者精華彙整。三講者兩專案，談國內網路的結構性風險，路由與對接、海纜資訊透明度、重要數位服務盤點不足，以及海纜問題的境外治理牽制與防災思維管理。

<p>小時候，以為海纜斷就是網路斷，我在這頭，世界在那頭。 長大後，以為滿格就是有服務，殊不知首頁在這頭，資料在那頭。 第一場海纜論壇後，才知道真正的斷線不是沒訊號，是什麼都像連上了，能用的卻都在海的那頭。</p> <p>「Section 1 海纜專題與技術報告」講者精華彙整，理解海纜與網路風險，看國外那頭前，先看看國內這頭。</p> <h2 id="三講者兩專案談國內網路的結構性風險">三講者兩專案，談國內網路的結構性風險</h2> <p>「網路服務」複雜性高，在於網路國內外都有連線，分層結構複雜。即使海纜只有部分斷掉、對外網路流量少了 50%，在「壅塞崩潰」的情境與驗證和授權逐一過期下，使用者仍可能感受到網路服務一層一層壞掉。壞哪層、影響什麼、怎麼補強，才是應對關鍵。</p> <p><strong>風險一：國內網路路由和對接（routing / peering）是商業模式問題。</strong> 若本地電信商彼此沒有對接，或「過路費談不攏」，原可以在國內網路互聯的服務，可能因此繞出去美國、日本等海外路徑再連回來。平常只差 20–30 毫秒，一旦網路限流或海纜異常，風險快速升高。</p> <p><strong>風險二：海纜資訊不透明，問題不易被看見。</strong> 國內／外海纜組成跟分段功能複雜，過去沒有海纜動態地圖時，電信公司常把網路變慢責任推給上下游廠商、數位服務提供者或外部責任，一般人很難準確判斷問題點。透過 OSINT 等公開圖資彙整成可視化資訊後，海纜狀態才變得可追蹤，更能讓全民意識到：網路變慢、服務失靈，未必只是單一業者或網站的問題。</p> <p><strong>風險三：台灣對重要數位基礎服務的盤點不足。</strong> 「數位服務韌性檢測」專案調查前 2,000 常用的網站服務首頁，指出海纜斷掉時 <strong>89% 的網站有危險</strong>，只要牽涉國內外資料中心、節點、雲端服務、主機、伺服器等多元分層架構，就可能受波及；如雲端服務就高度集中在 Google、Amazon、Cloudflare 等業者。同時，11% 通過測試也不代表真的安全：其資料庫、App、第三方資源服務與其它頁面，不一定建在國內。台灣真正的問題不只是海纜會不會斷，而是哪些服務最重要、關係鏈在哪裡、又有多少其實早已綁在境外。</p> <h2 id="接下來台灣怎麼做">接下來，台灣怎麼做</h2> <ul> <li>海纜相關資訊與措施要更公開透明：包含異常狀況、修復進度與風險說明，也應該推動常態性的測試與揭露，讓重要數位服務的脆弱點不必等到事故發生才被看見。</li> <li>增加國內 peering 管道、鼓勵電信業者彼此的合作互聯，減少原本能在國內打通的流量被迫繞到國外，降低海纜限流時的風險。</li> <li>盡快盤點公共建設與重要數位服務的依賴鏈，建立海內外備援方案，包括資料中心、雲端服務、驗證機制與關鍵民生系統。</li> <li>更～多～全民教育：讓社會理解海纜、網路與數位服務之間的關係。</li> </ul> <h2 id="海纜問題處理的境外治理牽制">海纜問題處理的境外治理牽制</h2> <p><strong>限制一：國界問題。</strong> 聯合國體制下，1982 年《海洋法公約》確立了海上管轄邊界：領海最寬不超過 12 海浬，鄰接區可到 24 海浬。因此，海纜乍看是無國界的基礎設施，卻不是哪裡斷了、鄰近政府就能直接開船去修，因為還牽涉海域管轄、船隻權限與跨國協調，這讓海纜的追蹤、保護與修復受限許多，狀況難以及時掌握，出事多要抓到現行犯才能究責。</p> <p><strong>限制二：資金現實。</strong> 公部門不可能用公家船隻直接進入他國海域處理海纜問題；私部門能用商港解決嗎？提到商，必先看資金。真正能做海纜修復的大型工作船，基本造價約 1–3 億美金，專業工作船營運成本約 1500 萬美金／年；且電信公司主要收益來自架設新海纜，不是修海纜，這也使得維護本身較難成為市場自然會優先投入的方向。</p> <h2 id="用防災思維管理數位基礎建設">用「防災」思維管理數位基礎建設</h2> <p>因應前述境外治理的牽制，海纜重造與維護十分困難，故應用災前、災中、災後的線性思維實行風險管理。</p> <ul> <li><strong>災前</strong>：降低海纜被破壞的機率，透過裁罰、沒收工具、加深埋設、物理防護與預警系統，墊高破壞成本；另一方面也要最小化衝擊，持續增加備援海纜、維護系統、資料備份等；同時鼓勵跨國合作，媒合資源使業者能多建海纜跟維護系統。</li> <li><strong>災中</strong>：一旦海纜中斷，重點是盡快把訊務切換到備援海纜或備援系統，同時透過海纜專區、業者通報與跨部會協作掌握狀況。</li> <li><strong>災後</strong>：台灣仍仰賴國外修復船支援，因此事後除了加速修復，更重要的是回頭檢討中斷原因，督促產業補強安全防護，並持續推動跨部會合作。</li> </ul> <h2 id="社群觀點與他國借鏡">社群觀點與他國借鏡</h2> <p>社群角度關注的是，海纜議題背後、斷網或大幅降速時社會怎麼繼續運作。與其只討論最壞情境，更重要的是把不同中斷程度、不同原因的風險寫成劇本，盤點高機率、高風險、最需要優先因應的情境，再透過社群協作與實際演練，把對策從想像落實到實際。第一島鏈面對的狀況較為接近，可參考如日本、菲律賓的防災演習策略、維修協防措施等。</p> <p>從烏克蘭案例來看，台灣應學習「複合攻擊」與「整體韌性」的思維。烏克蘭面對的不只是網路攻擊，還包括政府數位服務、電力系統與實體基礎設施同時受壓；其異地備援可以放在歐盟國家，台灣呢？實例比較下，更突顯出台灣要提早思考：資料中心控制層能不能在境內運作、必要流量如何分配、中央與地方不同規模中斷時，怎麼在危機中協調彼此等跨域協作問題。</p> Cyborg Resilience Co-lab https://crcolab.art/ideas/2026-03-25-crc-march-25-decks/ 2026-03-25T00:00:00+08:00

整理 CRC 於 2026 年三月數位韌性論壇的講者與延伸閱讀。

<p>原始講者與素材公開於 <a href="https://paulpengtw.github.io/crc-march-25-decks/">https://paulpengtw.github.io/crc-march-25-decks/</a> 。</p> <h2 id="主題大綱">主題大綱</h2> <p>2026 年三月數位韌性論壇，彭宬當時進行了「台灣對外網路流量 degrade 模擬」。模擬情境為海纜因地震導致斷裂、台灣對外頻寬瞬間損失 50%（*註一），接著逐段拆解對外頻寬銳減後 6 小時內可能會依序出現的故障，從打網路電話（如 LINE 語音或 Messenger 語音） 斷線、網頁卡住、App 可能會一個接一個壞掉、帳號一個一個登出、甚至是明明 Wi-Fi 訊號滿格，但可能什麼都連不上。</p> <p>這個演講就是想針對這些網路障礙背後的可能成因，以及這些網路障礙有哪些可能減緩影響的路徑？</p> <p>*註一：一半的海底電纜斷掉不等於失去一半的對外網路流量。</p> <div class="phase-header"> <span class="phase-badge phase-badge--1">0–5 min</span> <h2>第一階段：為什麼「網路電話」突然斷了</h2> </div> <h3 id="你可能會感受到的">你可能會感受到的</h3> <ul> <li>LINE 語音通話 → 機器人聲音 → 斷線 ☎️❌</li> <li>Instagram → 白畫面</li> <li>Google Drive → 載入一半，卡住不動</li> <li>看一眼右上角</li> </ul> <p><strong>Wi-Fi 訊號滿格 📶</strong></p> <h3 id="是-wifi-機的問題還是網路的問題">「是 WiFi 機的問題，還是網路的問題？」</h3> <p>Wi-Fi 訊號滿格 ≠ 網路正常</p> <div style="margin-top: 1em; text-align: left;"> <p>📱 → 📡 <strong>Wi-Fi</strong>：你的手機到你家路由器</p> <p style="color: #aaa;">這段完全正常 ✓</p> </div> <div style="text-align: left;"> <p>📡 → 🌏 <strong>網路</strong>：你家路由器到全世界</p> <p style="color: #e74c3c;">這段出事了 ✗</p> </div> <p>問題不在你家，在<strong>海底</strong>。</p> <h3 id="當代的網路到底是什麼">當代的網路到底是什麼？</h3> <p>想像網路是一個由<strong>幾千間郵局</strong>組成的系統。</p> <div style="margin-top: 1em;"> <p>🏣 每間郵局 = 一個網路機房（ISP、資料中心）</p> </div> <div> <p>✉️ 你的資料 = 一封封信件（封包）</p> </div> <div> <p>🛣️ 郵局之間有很多條路可以互相送信</p> </div> <p>你在台北寄信到東京，信會經過好幾間郵局，一站一站轉送過去。</p> <p>網路結構可以簡要的以郵局之間的關係來比喻。網路不是一條線，是很多節點互相轉送資料。每個 ISP、每個機房就像一間郵局。你的資料像信件，會被一站一站轉送到目的地。</p> <h3 id="郵局怎麼知道信要往哪送">郵局怎麼知道信要往哪送？</h3> <p>每間郵局門口都有一塊<strong>路牌</strong> 🪧</p> <div style="margin-top: 0.5em; background: rgba(255,255,255,0.05); padding: 0.8em; border-radius: 8px;"> <p style="text-align: left;">「要去日本？→ 交給南邊那間郵局」</p> <p style="text-align: left;">「要去美國？→ 交給東邊那間郵局」</p> <p style="text-align: left;">「要去高雄？→ 交給隔壁那間郵局」</p> </div> <p>這塊路牌，在網路世界叫做<strong>路由表</strong>。</p> <p>郵局之間互相更新路牌的方法，就叫 <strong>BGP</strong>（Border Gateway Protocol 邊界閘道協定）。</p> <p>路由表就是每個網路節點的「方向指引」。BGP 是全球網路用來同步這些路由資訊的協定。不需要記術語，只要記住：BGP = 郵局之間互相通知「路怎麼走」的系統。</p> <h3 id="海纜斷了--路斷了">海纜斷了 = 路斷了</h3> <p>光纖裡的光束<strong>直接消失</strong>（畢竟斷了）。</p> <p>離斷點最近的郵局第一個發現：<span style="color: #e74c3c;">「這條路不通了！」</span></p> <p>它立刻向鄰居廣播：「大家注意！往南的路斷了！不要再把信往這邊送了！」</p> <p style="color: #f39c12;">這則消息開始一間接一間傳開⋯⋯</p> <p>海纜是光纖，斷裂時光訊號直接消失，不是慢慢變弱，是瞬間歸零。連接在該纜線上的路由器（郵局）偵測到鏈路中斷，透過 BGP 向鄰居宣告：這條路已經失效。這個宣告會像漣漪一樣擴散到全球網路。</p> <h3 id="重新算路的混亂期">重新算路的混亂期</h3> <p style="color: #aaa;">BGP Reconvergence</p> <p>全球幾千間郵局同時收到消息，但不是<strong>同時</strong>收到。</p> <div style="margin-top: 0.8em; background: rgba(255,255,255,0.05); padding: 0.8em; border-radius: 8px;"> <p style="text-align: left;">🏣 A 郵局已經改路牌了 ✓</p> <p style="text-align: left;">🏣 B 郵局還不知道路斷了 ✗</p> <p style="text-align: left;">🏣 C 郵局收到了，但還在算新路線 ⏳</p> </div> <p>你的信被⋯⋯</p> <ul> <li>送到已經斷掉的路 → <strong>丟失</strong></li> <li>在兩間郵局之間來回彈 → <strong>繞圈</strong></li> <li>沒有郵局願意收 → <strong>退回</strong></li> </ul> <p style="color: #f39c12;">這段混亂期：30 秒 ~ 數分鐘</p> <p>BGP reconvergence 是整個網路重新達成共識的過程。問題在於：資訊傳播有延遲，各節點更新速度不同。在這段過渡期，路由表處於不一致狀態，有些路由器認為舊路還在，有些已經切換新路。這導致封包被丟棄、迴圈、或送進死胡同。時間長短取決於網路拓撲複雜度和 BGP 收斂速度。</p> <h3 id="對你來說可能就是全部斷了">對你來說，可能就是，全部斷了</h3> <div style="margin-top: 1em; text-align: left;"> <p>封包被丟掉 → 網頁可能載不出來</p> <p>封包繞遠路 → 延遲可能從 20ms 變 2000ms</p> <p>封包來回彈 → 可能根本到不了目的地</p> </div> <p>實際上 50% 的對外網路流量還在，但在路由重算完成之前，對一般人來說可能就是<strong>卡爆</strong>。</p> <p>50% 容量還在，但 BGP 收斂期間幾乎無法使用。這就像高速公路出了大車禍，雖然隔壁車道還通，但因為指示牌混亂，所有車都卡在交流道上動不了。一旦 BGP 收斂完成（所有郵局路牌更新一致），剩餘 50% 容量才能真正被利用，不過接下來會面臨壅塞問題。</p> <h3 id="假設-line-語音掛了但文字可能還活著">假設 LINE 語音掛了，但文字可能還活著？</h3> <div style="display: flex; justify-content: center; gap: 2em; flex-wrap: wrap;"> <div style="background: rgba(46,204,113,0.1); padding: 1em; border-radius: 8px; flex: 1; min-width: 250px; max-width: 350px;"> <p style="font-size: 1.2em;">💬 文字訊息</p> <p>很小的封包（可能僅幾 KB）</p> <p>能鑽過混亂的空隙</p> <p>晚幾秒到也沒差</p> </div> <div style="background: rgba(231,76,60,0.1); padding: 1em; border-radius: 8px; flex: 1; min-width: 250px; max-width: 350px;"> <p style="font-size: 1.2em;">🎙️ 語音通話</p> <p>持續的即時串流</p> <p>掉幾個封包 = 機器人聲</p> <p>延遲超過 300ms = 斷線</p> </div> </div> <div style="margin-top: 1.2em; border-top: 1px solid rgba(255,255,255,0.2); padding-top: 0.8em;"> <p>我們還不確定的是：</p> <p style="color: #e74c3c;"> LINE 的通話伺服器<strong>可能在日本？</strong><br /> 台灣的語音通話<strong>可能必須出海</strong>才能接通？ </p> </div> <div class="phase-header"> <span class="phase-badge phase-badge--2">5–30 min</span> <h2>第二階段：殭屍網路</h2> </div> <p>進入第二階段。BGP 已經收斂完成，路由穩定了。但民眾會發現：網路「活著」但幾乎不能用。這個階段要解釋兩件事：壅塞崩潰和 Trombone Effect。</p> <h3 id="你可能感受到的">你可能感受到的</h3> <ul> <li>網頁載入一半⋯⋯卡住不動</li> <li>圖片只出現一半，下面是灰色空白</li> <li>可能 YouTube 轉圈圈轉到天荒地老</li> <li>可能 LINE 文字勉強能傳，但要等很久才送達</li> </ul> <p>訊號滿格 📶 看似「有通」，<strong>但可能慢到幾乎不能用</strong>。</p> <p>跟第一階段不同，前面是是完全斷線（BGP 收斂期間）。現在是「有連線但極度緩慢」，這其實更讓人困惑。民眾會不斷重新整理、重試，反而讓情況更糟。</p> <h3 id="等欸路不是已經修好了嗎">等欸，路不是已經修好了嗎？</h3> <p>BGP reconvergence 完成 ✓，所有郵局的路牌已經更新一致。</p> <p>剩餘 50% 的對外網路流量正常運作 ✓，路是通的，信可以送。</p> <p style="color: #f39c12;">那為什麼還是這麼慢？</p> <p>路沒斷，但<strong style="color: #e74c3c;">路太擠了</strong>。</p> <p>前一個部分的問題是「路牌混亂」（BGP 收斂）。這一階段的問題是「路太少車太多」（壅塞崩潰）。兩個完全不同的故障機制，但對使用者來說感覺差不多。</p> <h3 id="想像一條高速公路">想像一條高速公路</h3> <p>台灣的對外網路流量 = 一條 <strong>10 線道</strong>的高速公路 🛣️</p> <p>假設平常車流量大約用了 <strong>7–8 線道</strong>，還有空間，大家都能順暢通行。</p> <p style="color: #e74c3c;">但失去 50% 對外流量 = 突然只剩 <strong>5 線道</strong></p> <p>但車流量沒有變，<strong>一樣多的車，一半的路</strong>。</p> <p>用高速公路來解釋壅塞。平常海纜利用率大約 40-60%，所以有餘裕。斷掉一半之後，剩餘容量立刻被塞滿，車流量不會因為路變少就自動減少。</p> <h3 id="塞車的連鎖反應">塞車的連鎖反應</h3> <p style="color: #aaa;">為什麼不是「慢一半」而是「幾乎不能動」？</p> <div style="background: rgba(255,255,255,0.05); padding: 0.8em; border-radius: 8px;"> <p style="text-align: left;">🚗 車太多，有些車擠不進去 → <strong>被丟包</strong></p> <p style="text-align: left;">🔄 被丟包的車說：「我再試一次！」 → <strong>重新上路</strong></p> <p style="text-align: left;">🚗🚗🚗 大家都在重試 → 路上的車<strong>反而更多了</strong></p> <p style="text-align: left;">💥 更多車被丟包 → 更多重試 → <strong>惡性循環</strong></p> </div> <p style="color: #e74c3c;">這就叫「壅塞崩潰」<br /><span style="color: #aaa;">Congestion Collapse</span></p> <p>這是壅塞崩潰的核心機制。TCP 協定在偵測到封包遺失時會重傳。但當所有連線同時重傳，反而製造更多流量，讓壅塞更嚴重，導致更多封包遺失，再觸發更多重傳。這個惡性循環就是 congestion collapse。</p> <h3 id="用寄信來理解">用寄信來理解</h3> <p style="color: #aaa;">（延續上一階段的郵局比喻）</p> <p>你寄了一封信到美國 ✉️</p> <p>路上太擠，信被丟了 → 你沒收到回信。</p> <p>你想：「大概寄丟了，再寄一次吧！」，你的電腦也是這樣想的（TCP 重傳）。</p> <p style="color: #f39c12;">假如全台灣 2,300 萬人的手機都在同一時間「再寄一次」⋯⋯</p> <p style="color: #e74c3c;">🏔️ 信件雪崩</p> <p>TCP 重傳機制在正常情況下很好用，偶爾掉一個封包就重送。但在全面壅塞時，所有人同時重送變成災難。這就像塞車時大家都猛按喇叭、硬切換車道，只會讓交通更癱瘓。</p> <p>物理容量 50% 不等於可用頻寬 50%，因為壅塞崩潰的非線性效應，當連結利用率超過某個臨界點，有效吞吐量急遽下降。部分研究顯示，在嚴重壅塞下，頻寬有效利用率可能降到 15-20%。</p> <h3 id="你可能會碰到的體驗">你可能會碰到的體驗</h3> <div style="text-align: left;"> <p>📄 網頁 → 可能文字出來了，圖片永遠在轉圈</p> <p>🎬 影片 → 可能 240p 馬賽克畫質，還一直暫停緩衝</p> <p>📥 下載 → 可能速度從 100 Mbps 掉到 2 Mbps</p> <p>📱 App → 可能開得起來，但操作什麼都要等 10 秒以上</p> </div> <p>可能不是斷線，但會<strong>卡到哭出來</strong> qq</p> <p>這邊可以具體感受壅塞崩潰的影響。「慢到不能用」比「完全斷線」更痛苦，因為你會一直重試、一直等待，浪費大量時間。而且你無法判斷是自己的問題還是整個網路所造成的問題。</p> <h3 id="接下來的問題更奇怪">接下來的問題更奇怪</h3> <p>有些網站明明伺服器<strong>就在台灣</strong>，理論上不需要走對外流量，不應該受影響。</p> <p style="color: #e74c3c;"><strong>但它們可能也壞了</strong> 🤯</p> <p>為什麼？</p> <p>壅塞崩潰解釋了「國際流量為什麼慢」。但接下來要解釋一個更詭異的現象：明明伺服器在台灣、不需要走海纜的服務，為什麼也壞了？這就要引入 Trombone Effect。</p> <h3 id="-便利商店的故事">🏪 便利商店的故事</h3> <p>你家巷口有一間 7-11，你想買一瓶水。</p> <p>正常情況：🏠 → 🚶 走路 30 秒 → 🏪 買到了！</p> <p>這就像你在台灣連一個<strong>台灣的伺服器</strong>，資料不用出海，直接在島內傳。</p> <p>便利商店比喻來解釋 Trombone Effect。伺服器在台灣，你也在台灣，資料直接在島內傳遞。像走路去巷口 7-11 買東西一樣簡單直接。</p> <h3 id="但有些電信商說">但有些電信商說⋯⋯</h3> <div style="background: rgba(231,76,60,0.1); padding: 1em; border-radius: 8px;"> <p>「不行！你不能直接去巷口那間！」</p> </div> <p>有些電信商規定的路線：</p> <div style="background: rgba(255,255,255,0.05); padding: 0.8em; border-radius: 8px;"> <p> 🏠 你家<br /> → ✈️ 先搭飛機去<strong>東京</strong><br /> → 🏪 在東京的 7-11 結帳<br /> → ✈️ 飛回台灣<br /> → 🏠 拿到你的水 </p> </div> <p style="color: #f39c12;">就為了一瓶巷口就有的水 🤦</p> <p>你的請求被迫出海繞一圈再回來。明明伺服器就在旁邊，但你的 ISP 的路由設定把流量送到日本或香港再繞回來，這確實很荒謬。</p> <h3 id="為什麼某些電信商要這樣繞">為什麼某些電信商要這樣繞？</h3> <p>因為台灣的電信商之間<strong>沒有在本地「牽手」</strong>。</p> <div style="background: rgba(255,255,255,0.05); padding: 0.8em; border-radius: 8px; text-align: left;"> <p>🤝 <strong>對等互連（Peering）</strong>：兩家廠商說好「你的使用者可以直接連我的伺服器」</p> <p style="margin-top: 0.5em;">🏢 <strong>網路交換中心</strong>：一個讓大家來牽手的地方</p> </div> <p style="color: #e74c3c;">問題：有些台灣 ISP 不是很喜歡跟別人牽手<br /><span style="color: #aaa;">或者分享很少的流量</span></p> <p>解釋 peering 和 Internet Exchange 的概念。用「牽手」比喻對等互連。TPIX 是台灣的網路交換中心之一，理論上 ISP 可以在這裡直接交換流量，不需要繞到海外。但現實是：很多 ISP（尤其大的）不願意在 TPIX 對等互連，因為它們覺得自己的網路比較大，不需要跟小的「牽手」，或者來了但只開放很小的頻寬。</p> <h3 id="平常你感覺不到">平常你感覺不到</h3> <p>繞去東京再回來只多 <strong>20–30 毫秒</strong>，你根本感覺不到差別。</p> <p>所以有些 ISP 覺得：「反正使用者不會發現，何必花錢在本地牽手？」</p> <p style="color: #e74c3c;">直到海纜出事：<strong>那條繞去台灣以外的路塞爆了</strong></p> <p style="color: #f39c12;">你的水瓶在東京的機場跑道上排隊</p> <h3 id="結果伺服器在你旁邊你卻連不上">結果：伺服器在你旁邊，你卻連不上</h3> <div style="display: flex; justify-content: center; gap: 1.5em; flex-wrap: wrap;"> <div style="background: rgba(255,255,255,0.05); padding: 0.8em; border-radius: 8px; min-width: 200px; text-align: center;"> <p>📍 伺服器位置</p> <p style="font-weight: bold;">台北內湖</p> <p style="color: #aaa;">離你 10 公里</p> </div> <div style="background: rgba(255,255,255,0.05); padding: 0.8em; border-radius: 8px; min-width: 200px; text-align: center;"> <p>📍 你的資料實際走的路</p> <p style="font-weight: bold;">台北 → 東京 → 台北</p> <p style="color: #aaa;">繞了 4,000 公里</p> </div> </div> <p style="color: #e74c3c;">對外網路流量壅塞 → 這段繞路卡死 → 你連 10 公里外的伺服器都連不上</p> <p>這就是 <strong>tromboning</strong> 🎺，「長號效應」：資料像長號的管子一樣繞一大圈。</p> <h3 id="這個階段的兩個可能主要瓶頸">這個階段的兩個可能主要瓶頸</h3> <div style="display: flex; justify-content: center; gap: 2em; flex-wrap: wrap;"> <div style="background: rgba(231,76,60,0.1); padding: 1em; border-radius: 8px; flex: 1; min-width: 250px; max-width: 380px;"> <p style="color: #e74c3c;">❶ 大塞車</p> <p>50% 對外流量 ≠ 50% 速度<br />可能的可用頻寬只剩 <strong>15–20%</strong></p> </div> <div style="background: rgba(243,156,18,0.1); padding: 1em; border-radius: 8px; flex: 1; min-width: 250px; max-width: 380px;"> <p style="color: #f39c12;">❷ 大繞路</p> <p>國內 peering 不夠好<br />本土流量被迫繞路<br />連<strong>本土伺服器</strong>都影響</p> </div> </div> <p>這兩個問題加在一起：<strong>「有網路」可能不等於「能用」</strong>。</p> <p>總結本階段的兩個核心概念。壅塞崩潰：物理容量和實際可用頻寬的非線性關係。Trombone Effect：路由政策讓不需要出海的流量也受害。兩者疊加造成「殭屍網路」：看起來活著，實際上幾乎不能用。</p> <h3 id="但更糟的可能還在後面">但更糟的可能還在後面⋯⋯</h3> <p>現在你能用的那些服務，Google 搜尋可能偶爾能出結果、一些網頁可能還看得到，它們之所以還活著，可能是因為<strong>「快取」</strong>：之前存在台灣的副本，可能暫時還能用。</p> <p>但快取有<strong>保存期限</strong>⋯⋯</p> <p style="color: #e74c3c;"><strong>時間一到，它們可能也會一個接一個壞掉 ⏳</strong></p> <p>目前還能用的服務，很多是靠 CDN 快取在撐。快取有 TTL（存活時間），一旦過期就要向海外原始伺服器要新的。但海纜壅塞，要不到 → 快取過期 → 服務掛掉。這個「逐步崩壞」的模式會在下一階段詳細解釋。</p> <div class="phase-header"> <span class="phase-badge phase-badge--3">30–60 min</span> <h2>第三階段：剛剛還好好的怎麼又壞了</h2> </div> <p>進入第三階段。壅塞已經穩定下來，ISP 開始做流量管理。但人們會發現一個詭異的現象：之前還能用的東西，開始一個一個壞掉。這個階段要解釋三個機制：CDN 快取過期、Auth Token 過期、DNS 快取過期。這三個機制造成的「漸進式崩壞」比完全斷線更危險，因為它讓人無法判斷問題在哪。</p> <h3 id="你感受到的">你感受到的</h3> <ul> <li>Google Drive 剛剛可能還能開，現在卡住了</li> <li>新聞網站可能文字有、圖片全消失</li> <li>LINE 可能閃退後重開，可能登不回去了</li> <li>網銀 app 可能要你重新輸入密碼，然後愛的魔力轉圈圈</li> </ul> <p>一次不會全壞，<strong>可能是一個一個壞掉</strong>，且看起來毫無規律。</p> <p>這種「漸進式故障」是最讓人困惑的。完全斷線大家反而知道「網路斷了」，會去找替代方案。但東西一個一個壞、有些還能用、有些不行，會讓人反覆嘗試、浪費時間、更焦慮。接下來我們要解釋為什麼會「一個一個壞」。答案是三種「保存期限」同時在倒數。</p> <h3 id="回到便利商店">回到便利商店</h3> <p>你家旁邊的 <strong>7-11</strong> 🏪，架上有飲料、便當、零食的「複製品」。</p> <p>這些商品從哪來？<strong>海外的倉庫</strong> 🚢，7-11 不生產東西，它從倉庫進貨、放在架上給你拿。</p> <p>網路世界也一樣，<strong>CDN</strong> 就是你家旁邊的數位便利商店（Content Delivery Network）。</p> <p>CDN = Content Delivery Network，內容傳遞網路。Cloudflare、Akamai、CloudFront 等公司在台灣設有「邊緣節點」（edge node）。這些節點就像便利商店：把海外伺服器的內容複製一份放在台灣，讓使用者不用每次都跑到海外去拿。你瀏覽的網頁圖片、CSS、JavaScript 檔案，很多都是從台灣的 CDN 節點送到你手上的。</p> <h3 id="保存期限ttl">保存期限：TTL</h3> <p style="color: #aaa;">Time To Live</p> <p>便利商店的便當有<strong>保存期限</strong>，過期了就不能賣，要從倉庫補新的。</p> <p>CDN 快取也有類似保存期限，叫做 <strong>TTL</strong>（Time To Live：這份複製品可以用多久）。</p> <p>TTL 可能是 <strong>5 分鐘</strong>，也可能是 <strong>24 小時</strong>，每個網站、每個檔案的設定都不同。</p> <p style="color: #f39c12;">前 30 分鐘大部分快取還沒到期，所以東西「還能用」。現在，保存期限開始一個一個到了。</p> <p>TTL 是伺服器設定的，告訴 CDN「這份複製品可以用多久」。新聞網站的首頁圖片可能 TTL 只有 5 分鐘（因為要即時更新）。jQuery 函式庫可能 TTL 有 1 年（因為幾乎不會變）。海纜剛斷的前 30 分鐘，大部分快取還在有效期內，所以使用者感覺「還行」。但隨著時間推移，各種快取的 TTL 陸續到期，問題就開始浮現。</p> <h3 id="便利商店補不到貨了">便利商店補不到貨了</h3> <p>架上的便當過期了 → 要從倉庫補貨。</p> <p style="color: #e74c3c;">但通往倉庫的路塞爆了 🚛💨</p> <p>（對外流量壅塞 = 國際連線極度緩慢）</p> <p>補貨卡車出發了⋯⋯但塞在路上回不來。CDN 向海外原始伺服器要新資料 → 逾時 → 失敗。</p> <p style="color: #e74c3c;"><strong>快取過期 + 補不到貨 = 架上空了</strong></p> <p>當 CDN 快取的 TTL 到期，CDN 節點會向海外的「原始伺服器」（origin server）發出 revalidation 請求。正常情況下這只需要幾十毫秒。但現在國際連線壅塞，這個請求要嘛超時、要嘛回應極慢。CDN 拿不到新資料，就不能繼續提供內容，使用者看到的就是載入失敗。</p> <h3 id="為什麼有些能看有些不行">為什麼有些能看、有些不行？</h3> <div style="display: flex; justify-content: center; gap: 2em; flex-wrap: wrap; margin-top: 0.8em;"> <div style="background: rgba(46,204,113,0.1); padding: 1em; border-radius: 8px; flex: 1; min-width: 250px; max-width: 350px;"> <p>✅ 還能看</p> <p style="color: #aaa;">熱門 YouTube 影片<br />常用網站的 CSS/JS<br />大家都在看的新聞圖片</p> <p style="color: #2ecc71;">→ 快取剛補過、TTL 還沒到</p> </div> <div style="background: rgba(231,76,60,0.1); padding: 1em; border-radius: 8px; flex: 1; min-width: 250px; max-width: 350px;"> <p>❌ 看不到了</p> <p style="color: #aaa;">冷門頁面、舊文章<br />你很久沒開的文件<br />TTL 短的即時內容</p> <p style="color: #e74c3c;">→ 快取已過期、補貨失敗</p> </div> </div> <p>這就是為什麼<strong>同一個網站有些部分能看、有些不行</strong>，結果以為是網站壞了，其實是快取到期的時間不同。</p> <p>這解釋了為什麼使用者會覺得故障「很隨機」。同一個網站，HTML 文字可能快取 TTL 24 小時（還有效），但圖片 TTL 只有 1 小時（已過期）。所以你會看到文字出現、但圖片全空白的詭異畫面。越多人同時存取的內容，快取越「新鮮」，因為一直有人觸發補貨。冷門內容則相反，快取很可能已經過期很久了。</p> <h3 id="什麼是-auth-token">什麼是 Auth Token？</h3> <p>假設我們去<strong>遊樂園</strong> 🎢</p> <p>去遊樂園，在入口<strong>買了票、驗了身分</strong>，然後工作人員在你手上蓋了一個<strong>章</strong>。</p> <p>我們用遊樂園的比喻來解釋 Auth Token。這個概念對非技術背景的讀者來說很陌生，但它是理解「為什麼 app 會一個一個登出」的關鍵。</p> <h3 id="手上的章--auth-token">手上的章 = Auth Token</h3> <p>蓋了章之後，你可以：</p> <ul> <li>玩雲霄飛車 🎢 — 給工作人員看手上的章 ✓</li> <li>玩旋轉木馬 🎠 — 看章 ✓</li> <li>買園區餐點 🍔 — 看章 ✓</li> </ul> <p>每次不用重新排隊買票、重新驗身分。手上的章就代表「這個人已經驗證過了」。</p> <p><strong>Auth Token 就是你手上的那個章。</strong> 你登入 Google 之後，瀏覽器拿到一個「章」，之後開 Gmail、Drive、YouTube 都不用重新登入。</p> <p>Auth Token 就是這個「章」。你在 Google 登入一次，瀏覽器就拿到一個 token。之後你開 Gmail、Google Drive、YouTube，每次請求都帶著這個 token。伺服器看到 token 就知道「這是已經登入的使用者」，不用每次都問你帳號密碼。</p> <h3 id="但印章會褪色">但印章會褪色</h3> <p>遊樂園的章用的是<strong style="color: #f39c12;">特殊墨水</strong>，15 分鐘到 1 小時後，章就會褪色、看不到了。</p> <p>為什麼不用永久的墨水？</p> <div style="background: rgba(231,76,60,0.1); padding: 0.8em; border-radius: 8px;"> <p style="text-align: left;">🔒 如果有人<strong>偷印了你的章</strong>（token 被盜）</p> <p style="text-align: left; color: #aaa;">用褪色墨水 → 小偷最多用 15 分鐘</p> <p style="text-align: left; color: #aaa;">用永久墨水 → 小偷可以<strong>永遠冒充你</strong></p> </div> <p>所以 token 故意設計成會過期：安全機制。</p> <p>Token 設計成短期有效是一個安全決策。如果 token 永遠有效，一旦被竊取（例如透過 XSS 攻擊、中間人攻擊），攻擊者就能永遠冒充你。短期 token 限制了被盜後的損害範圍：就算被偷，15 分鐘後就失效了。這就像信用卡的到期日，不是為了方便你，是為了限制被盜用的風險。</p> <h3 id="章褪色了回售票口重蓋">章褪色了，回售票口重蓋</h3> <p>章褪色了 → 走回入口售票處 🎫，出示你的年票卡，工作人員重新蓋章，整個過程只要幾秒鐘，你幾乎不會注意到。</p> <p>平常這完全不是問題，app 在背景自動幫你「重蓋章」，你根本感覺不到。</p> <p style="color: #e74c3c;">但是⋯⋯如果售票處在<strong>海的另一邊</strong>呢？</p> <p>正常情況下，token 過期後的「重新認證」是背景自動完成的。瀏覽器或 app 會自動用 refresh token（像年票卡）去跟認證伺服器要新的 access token。整個過程幾百毫秒，使用者完全無感。但關鍵問題來了：認證伺服器在哪裡？</p> <h3 id="售票處在海的另一邊">售票處在海的另一邊</h3> <ul> <li>Google 的認證伺服器 可能在 🇺🇸 美國</li> <li>LINE 的認證伺服器 可能在 🇯🇵 日本</li> <li>Microsoft 的認證伺服器 可能在 🇺🇸 美國</li> </ul> <p>你的章褪色了 → 可能要跨海去重新蓋章。</p> <p style="color: #e74c3c;">但對外流量雍塞 = 那條路大塞車 🚗🚗🚗</p> <p>重新蓋章的請求<strong>送出去了⋯⋯但回不來</strong>，等了 30 秒 → 逾時 → 失敗。</p> <p style="color: #e74c3c;"><strong>你被登出了。而且登不回去。</strong></p> <p>這是 Auth Token 在海纜事件中的核心問題。Google 的 OAuth 認證伺服器主要在美國（accounts.google.com 解析到美國 IP）。LINE 的認證走日本的伺服器。Microsoft 的 Azure AD 也在美國。Token 過期後，app 嘗試跟這些海外伺服器重新認證。但國際連線壅塞，請求逾時，你就被登出了。而且登入頁面本身也需要連到海外伺服器，所以連「重新登入」都做不到。</p> <h3 id="每個人在不同時間被登出">每個人在不同時間被登出</h3> <div style="background: rgba(255,255,255,0.05); padding: 0.8em; border-radius: 8px;"> <p style="text-align: left;"> ⏱️ 斷纜後 20 分鐘：<span style="color: #e74c3c;">Google Drive</span> 的章可能褪色了 → 可能被登出<br /> ⏱️ 斷纜後 35 分鐘：<span style="color: #e74c3c;">LINE</span> 的章可能褪色了 → 可能閃退後登不回去<br /> ⏱️ 斷纜後 45 分鐘：<span style="color: #e74c3c;">網路銀行</span> 的章褪色了 → 要求重新登入 → 失敗<br /> ⏱️ 斷纜後 50 分鐘：<span style="color: #e74c3c;">公司 Slack</span> 的章可能褪色了 → 可能完全斷線 </p> </div> <p style="color: #f39c12;">這就是為什麼看起來「毫無規律」，因為每個 app 的章在不同時間褪色。</p> <p>每個服務的 token 有效期不同：Google 通常 1 小時，有些銀行 app 15 分鐘。而且每個使用者上次登入的時間不同，所以 token 到期的時間也不同。這就造成了「漸進式故障」的混亂局面：你隔壁同事的 Google Drive 還能用（因為他剛登入），你的已經不行了（因為你的 token 剛好到期）。大家互相詢問「你的能不能用？」得到不同答案，更加困惑。</p> <h3 id="token-的真面目">Token 的真面目</h3> <p>技術上，Token 長這樣：</p> <div style="background: rgba(255,255,255,0.05); padding: 0.8em; border-radius: 8px; font-family: monospace; font-size: 0.7em; word-break: break-all; text-align: left;"> eyJhbGciOiJSUzI1NiJ9.<span style="color: #3498db;">eyJ1c2VyIjoi5bCP5piOIiwic2NvcGUiOiJkcml2ZSIsImV4cCI6MTcxMTEyMzQ1Nn0</span>.SflKxwRJSMeKKF2QT4fw </div> <p>這叫 <strong>JWT</strong>（JSON Web Token），裡面包含：</p> <div style="display: flex; justify-content: center; gap: 1.5em; flex-wrap: wrap; margin-top: 0.5em;"> <div style="background: rgba(52,152,219,0.1); padding: 0.6em 1em; border-radius: 8px;"> <p style="margin: 0;">👤 你是誰</p> <p style="margin: 0; color: #aaa; font-size: 0.8em;">user: 小明</p> </div> <div style="background: rgba(52,152,219,0.1); padding: 0.6em 1em; border-radius: 8px;"> <p style="margin: 0;">🔑 能做什麼</p> <p style="margin: 0; color: #aaa; font-size: 0.8em;">scope: drive</p> </div> <div style="background: rgba(52,152,219,0.1); padding: 0.6em 1em; border-radius: 8px;"> <p style="margin: 0;">⏰ 何時到期</p> <p style="margin: 0; color: #aaa; font-size: 0.8em;">exp: 1 hr</p> </div> </div> <p>最後一段是<strong>數位簽章</strong>：防止偽造，只有伺服器能產生。</p> <p>JWT 是目前最常見的 token 格式。它分為三段（用 . 分隔）：header（演算法）、payload（內容）、signature（簽章）。中間的 payload 段用 base64 編碼，裡面就是 JSON 資料。重點是最後的 signature：它是用伺服器的私鑰簽的，所以沒人能偽造。伺服器收到 token 時，驗證簽章就知道這是不是自己發的。</p> <h3 id="token-的一生">Token 的一生</h3> <div style="max-width: 90%;"> <div style="background: rgba(46,204,113,0.1); padding: 0.6em 1em; border-radius: 8px; margin-bottom: 0.5em;"> <p style="text-align: left; margin: 0;">1️⃣ <strong>登入</strong>：輸入帳號密碼 → 伺服器給你兩個東西</p> <p style="text-align: left; margin: 0; color: #aaa; font-size: 0.9em;">　　Access Token（通行章）有效 15 分鐘～1 小時</p> <p style="text-align: left; margin: 0; color: #aaa; font-size: 0.9em;">　　Refresh Token（年票卡）有效數天～數週</p> </div> <div style="background: rgba(52,152,219,0.1); padding: 0.6em 1em; border-radius: 8px; margin-bottom: 0.5em;"> <p style="text-align: left; margin: 0;">2️⃣ <strong>使用中</strong>：每次操作都帶著 Access Token</p> <p style="text-align: left; margin: 0; color: #aaa; font-size: 0.9em;">　　伺服器看章就放行，不用每次都驗密碼</p> </div> <div style="background: rgba(243,156,18,0.1); padding: 0.6em 1em; border-radius: 8px; margin-bottom: 0.5em;"> <p style="text-align: left; margin: 0;">3️⃣ <strong>章褪色</strong>：Access Token 到期 → 用 Refresh Token 自動換新章</p> <p style="text-align: left; margin: 0; color: #aaa; font-size: 0.9em;">　　背景自動完成，你完全不會發現</p> </div> <div style="background: rgba(231,76,60,0.1); padding: 0.6em 1em; border-radius: 8px;"> <p style="text-align: left; margin: 0;">4️⃣ <strong>年票也到期</strong>：Refresh Token 也失效 → 必須重新輸入帳號密碼</p> <p style="text-align: left; margin: 0; color: #aaa; font-size: 0.9em;">　　這就是為什麼你偶爾會被要求「重新登入」</p> </div> </div> <p>OAuth 2.0 的標準流程。Access Token 是短期的（像蓋在手上的章），Refresh Token 是長期的（像年票卡）。正常情況下，Access Token 到期時，app 會自動用 Refresh Token 去跟伺服器換新的 Access Token。這整個流程在背景發生，使用者毫無感覺。只有當 Refresh Token 也到期（通常幾天到幾週），才會要求使用者重新輸入帳號密碼。</p> <h3 id="為什麼不能給永久通行證">為什麼不能給永久通行證？</h3> <div style="display: flex; justify-content: center; gap: 2em; flex-wrap: wrap;"> <div style="background: rgba(231,76,60,0.1); padding: 1em; border-radius: 8px; flex: 1; min-width: 250px; max-width: 350px;"> <p>🔓 如果 Token 永久有效</p> <p style="color: #aaa;">被偷了 → 攻擊者永遠能冒充你</p> <p style="color: #aaa;">權限變了 → 舊 token 還有舊權限</p> <p style="color: #aaa;">離職了 → token 還能用</p> </div> <div style="background: rgba(46,204,113,0.1); padding: 1em; border-radius: 8px; flex: 1; min-width: 250px; max-width: 350px;"> <p>🔒 Token 定期過期</p> <p style="color: #aaa;">被偷了 → 最多 15 分鐘就失效</p> <p style="color: #aaa;">權限變了 → 下次換發會更新</p> <p style="color: #aaa;">離職了 → token 自然失效</p> </div> </div> <p>Token 過期不是設計缺陷，是<strong style="color: #2ecc71;">安全機制</strong>，就像門鎖密碼定期更換：不方便，但更安全。</p> <p>這是安全與便利的根本取捨。永久 token 就像一把永遠不換的鑰匙，方便，但一旦被複製就完蛋。短期 token 就像定期更換的密碼鎖，麻煩，但被破解的損害有限。在正常網路環境下，這個取捨很合理：重新認證只要幾百毫秒，使用者無感。但在海纜事件中，「重新認證」這個步驟突然變成了致命弱點。</p> <h3 id="海纜斷裂時可能的連鎖反應">海纜斷裂時可能的連鎖反應</h3> <div style="max-width: 90%;"> <div style="border-left: 3px solid #3498db; padding-left: 1em; margin-bottom: 0.5em;"> <p style="margin: 0;">Access Token 到期</p> <p style="margin: 0; color: #aaa; font-size: 0.9em;">app 可能在背景嘗試用 Refresh Token 換新的</p> </div> <div style="border-left: 3px solid #f39c12; padding-left: 1em; margin-bottom: 0.5em;"> <p style="margin: 0;">Refresh 可能請求送往海外認證伺服器</p> <p style="margin: 0; color: #aaa; font-size: 0.9em;">但國際連線壅塞⋯⋯等 10 秒、20 秒⋯⋯</p> </div> <div style="border-left: 3px solid #e74c3c; padding-left: 1em; margin-bottom: 0.5em;"> <p style="margin: 0; color: #e74c3c;">逾時失敗 ✗</p> <p style="margin: 0; color: #aaa; font-size: 0.9em;">app 判定「認證失效」→ 可能強制登出</p> </div> <div style="border-left: 3px solid #e74c3c; padding-left: 1em; margin-bottom: 0.5em;"> <p style="margin: 0;">跳出登入頁面 → 你輸入帳號密碼</p> <p style="margin: 0; color: #e74c3c; font-size: 0.9em;">但登入頁面本身可能也要連到海外伺服器 → 也逾時 ✗</p> </div> </div> <p style="color: #e74c3c;"><strong>登出了，而且可能登不回去。</strong></p> <p>這是一個連鎖失敗：</p> <ol> <li>Access Token 過期（正常機制）</li> <li>Refresh 請求因為壅塞而逾時（不正常）</li> <li>App 判定認證失效，強制登出（正常反應）</li> <li>使用者嘗試重新登入，但登入流程本身也需要國際連線（致命弱點）</li> </ol> <p>特別是 OAuth 登入流程，「用 Google 登入」按鈕要連到 accounts.google.com，而那個伺服器在美國。所以連登入頁面都打不開。</p> <h3 id="你的-app-可能正在一個一個登出">你的 App 可能正在一個一個登出</h3> <div style="background: rgba(255,255,255,0.05); padding: 0.8em; border-radius: 8px;"> <p style="text-align: left;"> <span style="color: #2ecc71;">t+0 min</span>　對外流量驟降：所有 Token 開始倒數<br /> <span style="color: #2ecc71;">t+15 min</span>　<span style="color: #aaa;">網銀 token 到期 → 被登出</span><br /> <span style="color: #f39c12;">t+25 min</span>　<span style="color: #aaa;">Slack token 到期 → 可能離線</span><br /> <span style="color: #f39c12;">t+35 min</span>　<span style="color: #aaa;">LINE 需要重新驗證 → 可能失敗</span><br /> <span style="color: #e74c3c;">t+45 min</span>　<span style="color: #aaa;">Google Drive token 到期 → 可能無法存取文件</span><br /> <span style="color: #e74c3c;">t+60 min</span>　<span style="color: #aaa;">可能幾乎所有需要認證的服務都已失效</span> </p> </div> <p>「一次斷線」不太可能發生，<strong style="color: #e74c3c;">比較像慢動作的大規模登出</strong>。每個人、每個 app、不同時間：看起來完全隨機。</p> <p>這邊把整個 auth token 故事做一個時間軸總結。重點是讓大家理解：這不是「網路斷了」這麼簡單。而是一個看不見的倒數計時器在每個 app 裡面跑著，到期的那一刻，那個 app 就「死」了。而且因為每個服務的 token 有效期不同、每個人登入的時間不同，所以整個過程看起來完全隨機、毫無規律。</p> <h3 id="接下來dns">接下來：DNS</h3> <p>CDN 快取到期 → 內容消失。Auth Token 到期 → 被登出。</p> <p style="color: #f39c12;">還有第三個東西也在倒數⋯⋯</p> <p>而且這個東西壞掉的話，<strong>連網站在哪都找不到</strong>。</p> <p>前面兩個問題是「內容拿不到」和「身分認不了」。第三個問題更根本：「地址都查不到」。所以我們需要從最基礎開始解釋。</p> <h3 id="什麼是-dns網路的電話簿">什麼是 DNS？網路的電話簿</h3> <p>你在瀏覽器打 <strong>google.com</strong>，但電腦不懂「google.com」是什麼。</p> <p>電腦只懂<strong>數字地址</strong>：<span style="color: #3498db;">142.250.185.46</span>，這叫 IP 位址：像電話號碼一樣，每台伺服器都有一組。</p> <p><strong>DNS</strong> = 一本電話簿 📒，把「名字」翻譯成「電話號碼」（google.com → 142.250.185.46）。</p> <p style="color: #f39c12;">沒有這本電話簿，你就算知道對方的名字也打不了電話。</p> <p>DNS = Domain Name System（網域名稱系統）。我們用網址（domain name）上網，但電腦之間溝通用的是 IP 位址。DNS 就是中間的翻譯層，把人看得懂的名字轉成電腦看得懂的數字。沒有 DNS，你就必須記住每個網站的 IP 位址才能上網，就像沒有通訊錄就要背所有人的電話號碼。</p> <h3 id="dns-怎麼查像打-104-查號台">DNS 怎麼查？像打 104 查號台</h3> <p>你的手機想找 <strong>google.com</strong> 的電話號碼：</p> <div style="max-width: 90%;"> <div style="border-left: 3px solid #3498db; padding-left: 1em; margin-bottom: 0.4em;"> <p style="margin: 0;">1️⃣ 先翻自己的通訊錄（本機快取）</p> <p style="margin: 0; color: #aaa; font-size: 0.85em;">之前查過就直接用，不用再問別人</p> </div> <div style="border-left: 3px solid #3498db; padding-left: 1em; margin-bottom: 0.4em;"> <p style="margin: 0;">2️⃣ 沒有 → 打給 ISP 的查號台（DNS 解析器）</p> <p style="margin: 0; color: #aaa; font-size: 0.85em;">你的中華電信 / 台灣大 有一台專門幫你查號碼的伺服器</p> </div> <div style="border-left: 3px solid #3498db; padding-left: 1em; margin-bottom: 0.4em;"> <p style="margin: 0;">3️⃣ ISP 也沒有 → 一路往上問到「總機」</p> <p style="margin: 0; color: #aaa; font-size: 0.85em;">Root Server → .com 管理者 → google.com 的權威伺服器</p> </div> <div style="border-left: 3px solid #2ecc71; padding-left: 1em;"> <p style="margin: 0; color: #2ecc71;">4️⃣ 查到了！把結果記在通訊錄裡下次用</p> <p style="margin: 0; color: #aaa; font-size: 0.85em;">這就是「DNS 快取」：記住查到的結果，省得每次都打電話問</p> </div> </div> <p>DNS 查詢的層級：</p> <ol> <li>本機快取（你的裝置記住之前查過的結果）</li> <li>ISP 的 DNS 解析器（像 8.8.8.8 或中華電信的 DNS）</li> <li>根伺服器（Root Server）→ TLD 伺服器（管 .com 的）→ 權威伺服器（google.com 的管理者）</li> </ol> <p>正常這整個流程只要幾十毫秒。而且查到的結果會被快取在各個層級，下次再查就不用從頭問。但快取也有保存期限。</p> <h3 id="dns-快取也有保存期限">DNS 快取也有保存期限</h3> <p>通訊錄裡的電話號碼也會「過期」，google.com 的 TTL 可能設 300 秒（5 分鐘），某些 .tw 網站可能設 3600 秒（1 小時）。</p> <p>為什麼不永久記住？因為伺服器可能搬家（換 IP）、做負載平衡、或做故障切換。如果永遠用舊號碼，可能打到空號。</p> <p style="color: #f39c12;">所以 DNS 快取也有 TTL：過期就要<strong>重新查號</strong>，平常幾十毫秒搞定，你完全不會發現。</p> <p>DNS 記錄的 TTL 由網站管理者設定。大型網站通常 TTL 很短（幾分鐘），因為需要經常調整流量分配。小網站可能 TTL 較長（幾小時到一天）。正常情況下 DNS 重新查詢很快，但在海纜事件中，很多網站的權威 DNS 伺服器在海外，重新查詢就要走壅塞的國際連線。</p> <h3 id="dns-快取過期--找不到門牌號碼">DNS 快取過期 = 找不到門牌號碼</h3> <p>假設有一個網站 <strong>service.gov.tw</strong>，伺服器就在台北市內 🏢。</p> <p>你的裝置之前查過，通訊錄裡有它的 IP → 連線正常、速度快 ✓</p> <p>但 DNS 快取到期了：需要重新查號。權威 DNS 伺服器在哪？<span style="color: #e74c3c;">可能在美國（e.g. AWS Route 53）</span></p> <p style="color: #e74c3c;">查號的電話打不通 → 你<strong>查不到門牌號碼</strong>，伺服器就在 10 公里外：但你找不到它。</p> <p>不是伺服器掛了，不是網路斷了，<strong style="color: #f39c12;">是你忘了地址，而且問不到</strong>。</p> <p>這是 DNS 快取過期最諷刺的場景：一個 .tw 網站，伺服器實體在台灣，資料在台灣，完全不需要國際連線。但它的 DNS 權威伺服器用的是 AWS Route 53（在美國）。當你的 DNS 快取過期，需要重新查詢時，查詢請求要送到美國，經過壅塞的海纜，然後逾時。結果：一個完全在台灣的服務，因為 DNS 查不到而無法連線。這就是「依賴鏈」的概念，表面上是本土服務，實際上隱藏了海外依賴。</p> <div class="phase-header"> <span class="phase-badge phase-badge--4">1–6 hr</span> <h2>第四階段以後：控制平面依賴海外</h2> </div> <p>進入第四階段。海纜斷裂已經超過一小時了。BGP 早就重新收斂完成，壅塞也穩定下來，各種快取和 token 過期的「漸進式崩壞」也差不多走完了。但大家會發現一個新的現象：有些東西開始恢復了，但另一些東西卻完全死掉。這個階段要解釋兩件事：(1) ISP 開始手動做流量管理，(2) 雲端的「控制平面」依賴海外。這兩個機制共同造成了一條新的分水嶺：純國內的服務活了，有海外大腦的服務死了。</p> <h3 id="你感受到的-1">你感受到的</h3> <ul> <li>LINE 文字訊息：可能又通了！ ✅</li> <li>一些之前看過的網頁：可能可以開</li> <li>YouTube：可能能看，但畫質可能剩 144p 馬賽克</li> <li>Instagram：可能文字有，圖片全是灰框 🖼️❌</li> <li>要登入任何 SaaS 工具：可能轉圈圈、失敗</li> <li>AWS / GCP 管理後台：可能完全打不開</li> </ul> <p>出現了一條<strong>新的分水嶺</strong>，能用 vs 不能用，取決於服務的「大腦」在哪裡。</p> <p>這個階段的關鍵感受是「不公平」：為什麼有些東西恢復了，有些反而更慘？LINE 文字恢復是因為 ISP 開始做流量管理，把訊息列為高優先。SaaS 和雲端後台完全掛掉，是因為它們的「控制平面」在海外。接下來我們分兩部分解釋：(1) ISP 在做什麼，(2) 雲端的「大腦在海外」問題。</p> <h3 id="isp-在幕後做了什麼">ISP 在幕後做了什麼？</h3> <p>假設在<strong>急診室</strong> 🏥</p> <p>如果有重大災難，<strong>大量傷患湧入急診室</strong>，醫生人力有限，不可能同時救所有人，所以急診室有<strong>檢傷分類</strong>。</p> <p>這裡用急診室的比喻來解釋 ISP 的 QoS 或稱流量工程（traffic engineering）。海纜斷裂後，國際頻寬只剩一半，但流量需求沒有減少，就像大量傷患湧入但醫生不夠。ISP 的網路工程師這時候必須手動介入，決定哪些流量優先通過。這就是網路世界的「檢傷分類」（triage）。</p> <h3 id="檢傷分類誰先救">檢傷分類：誰先救？</h3> <div style="display: flex; justify-content: center; gap: 1em; flex-wrap: wrap;"> <div style="background: rgba(231,76,60,0.15); padding: 0.8em; border-radius: 8px; flex: 1; min-width: 180px; max-width: 250px; border-left: 4px solid #e74c3c;"> <p style="color: #e74c3c;">🔴 可能最優先</p> <p style="color: #aaa; font-size: 0.85em;">DNS 查詢<br />政府網站<br />即時訊息（LINE 文字）<br />金融交易</p> </div> <div style="background: rgba(243,156,18,0.15); padding: 0.8em; border-radius: 8px; flex: 1; min-width: 180px; max-width: 250px; border-left: 4px solid #f39c12;"> <p style="color: #f39c12;">🟡 可能次優先</p> <p style="color: #aaa; font-size: 0.85em;">一般網頁瀏覽<br />Email 收發<br />低解析度串流</p> </div> <div style="background: rgba(46,204,113,0.15); padding: 0.8em; border-radius: 8px; flex: 1; min-width: 180px; max-width: 250px; border-left: 4px solid #2ecc71;"> <p style="color: #2ecc71;">🟢 可能可延後</p> <p style="color: #aaa; font-size: 0.85em;">YouTube 高畫質<br />Instagram 圖片/影片<br />軟體更新下載<br />雲端備份</p> </div> </div> <p>ISP 工程師<strong>可能會手動介入</strong>，可能會決定誰的封包優先通過，這就是為什麼有些東西「恢復了」、有些變更慢。</p> <p>ISP 的流量管理（traffic engineering）在正常情況下大多是自動化的。但在海纜事件中，工程師會手動介入，設定 QoS（Quality of Service）規則。DNS 和政府網站被列為最高優先，因為 DNS 是所有網路服務的基礎。即時訊息（LINE 文字）流量小但對民眾影響大，所以也被優先處理。YouTube、Instagram 的圖片和影片流量極大（佔總流量的高比例），被降級處理。這就是為什麼你會看到 YouTube 畫質驟降、Instagram 只有文字沒有圖片。</p> <h3 id="為什麼-line-文字可能恢復了">為什麼 LINE 文字可能恢復了？</h3> <p>1️⃣ LINE 文字訊息 = <strong>相對小的封包</strong>，一則文字訊息可能大約 1 KB，一張 Instagram 照片可能大約 2,000 KB，差 <strong>2000 倍</strong>。</p> <p>2️⃣ ISP 可能把訊息列為<strong>高優先</strong>，小封包 + 本地路由 + 高優先 = 可能擠得過去 ✅</p> <p style="color: #f39c12;">Instagram 圖片？大封包 + 海外來源 + 可能被降級 = 可能轉圈圈 🖼️</p> <p>LINE 文字訊息能恢復有三個原因疊加：(1) 封包極小，文字訊息的資料量微不足道，就算頻寬極度壅塞也能擠過去。(2) LINE 在 TPIX（台灣網際網路交換中心）有對等連線，代表很多 LINE 文字訊息其實走島內路由，根本不需要經過海纜。(3) ISP 的流量管理把即時訊息列為高優先，在檢傷分類中排在前面。三個因素加起來，LINE 文字訊息就恢復了。相比之下，Instagram 照片動輒數 MB，來源在海外，又被降級，所以只剩灰框。</p> <h3 id="你的網路可能不是壞了可能是被管了">你的網路可能不是壞了：可能是被「管」了</h3> <p>🚦 ISP 工程師 = <strong>十字路口的交通警察</strong></p> <p>正常時候：綠燈，所有車都能過，你感覺不到交通警察的存在。</p> <p>危機時候：警察出來指揮 🖐️，「救護車先走！公車可以過！私家車等一下！」</p> <p>你的 YouTube 可能不是「斷了」，是被<strong>可能讓道</strong>給更重要的東西了。</p> <p>這里的重點是讀者理解：此刻他們感受到的「部分恢復」不是隨機的，而是 ISP 工程師刻意決策的結果。ISP 有能力區分不同類型的流量，也有能力決定優先順序。平常你不會注意到，因為頻寬足夠、所有人都能通過。但在頻寬緊縮的時刻，ISP 的「選擇」就直接決定了你能用什麼、不能用什麼。</p> <h3 id="這代表什麼一件你該知道的事">這代表什麼？一件你該知道的事</h3> <div style="background: rgba(52,152,219,0.1); padding: 1em; border-radius: 8px; text-align: left;"> <p>ISP <strong>有能力</strong>, ），他們知道哪些封包去哪裡、是什麼類型</p> </div> <div style="background: rgba(243,156,18,0.1); padding: 1em; border-radius: 8px; margin-top: 0.8em; text-align: left;"> <p>這代表 ISP <strong>平時的路由決策</strong>也是「選擇」，可能把你的流量繞去國外再繞回來，不在本土做對等連線</p> </div> <p style="color: #e74c3c;"><strong>危機時 ISP 能選擇救誰，代表平時 ISP 也在選擇犧牲誰</strong></p> <p>這是 ISP 流量管理段落的核心洞見。大家剛看到 ISP 在危機中有能力做流量分類和優先排序，這代表 ISP 平時也有這個能力。階段2 講到的長號效應，ISP 把本地流量繞去東京再繞回來，不是技術限制，是成本考量下的選擇。不在 TPIX 做本地對等連線，也是選擇。這個段落把階段2 的批判和階段4 的觀察連結起來：ISP 不是被動的管道，是有能力、有選擇、該被追究的行動者。</p> <h3 id="接下來雲端的問題">接下來：雲端的問題</h3> <p>LINE 文字可能恢復了、可能一些網頁能看了，但 SaaS 工具和雲端服務<strong>可能完全死掉</strong>。</p> <p>要理解為什麼，我們需要先搞懂一件事：<strong>「雲端」到底是什麼？</strong> ☁️🤔</p> <p>轉場到雲端控制平面的部分。很多人對「雲端」的理解停留在很模糊的層次，「資料存在雲上」。我們需要先把「雲端」講清楚，才能解釋為什麼「台灣的雲端」不等於安全。</p> <h3 id="雲端其實是別人的電腦">「雲端」其實是⋯⋯別人的電腦</h3> <p>你聽過「資料存在雲端」☁️，聽起來很輕盈、很抽象、飄在天上。</p> <p>真相：<strong>你的資料存在別人的電腦裡。</strong> 那台電腦放在一棟巨大的建築物裡，有空調、有保全、有備用發電機。這棟建築叫做<strong>「資料中心」（Data Center）</strong>。</p> <p>台灣有這樣的建築物 🏢，AWS、GCP 都有台灣機房。你的資料<strong>確實</strong>存在台灣的土地上 ✓</p> <p>先破除「雲端」的抽象感。很多人聽到「雲端」就覺得資料飄在某個虛無的空間裡。但雲端就是別人的電腦，放在大型資料中心裡。AWS 在 2022 年啟用了台灣區域（ap-northeast-3 → 實際是板橋的資料中心）。GCP 在彰化也有資料中心。所以「資料在台灣」這句話在物理上是成立的，但接下來要解釋為什麼這還不夠。</p> <h3 id="工廠和總部">工廠和總部</h3> <p>想像一家<strong>跨國企業</strong>在台灣設了一座<strong>工廠</strong>：</p> <div style="display: flex; justify-content: center; gap: 2em; flex-wrap: wrap;"> <div style="background: rgba(46,204,113,0.1); padding: 1em; border-radius: 8px; flex: 1; min-width: 240px; max-width: 320px;"> <p>🏭 台灣工廠</p> <p style="color: #aaa;">生產產品（存你的檔案）</p> <p style="color: #aaa;">出貨給客戶（回應你的請求）</p> <p style="color: #aaa;">倉庫裡有原料（你的資料）</p> <p style="color: #2ecc71;">→ 這叫「資料平面」Data Plane</p> </div> <div style="background: rgba(231,76,60,0.1); padding: 1em; border-radius: 8px; flex: 1; min-width: 240px; max-width: 320px;"> <p>🏢 美國總部</p> <p style="color: #aaa;">核發員工證（身分驗證 IAM）</p> <p style="color: #aaa;">核准預算（配置資源）</p> <p style="color: #aaa;">簽發合約（SSL 憑證）</p> <p style="color: #e74c3c;">→ 這叫「控制平面」Control Plane</p> </div> </div> <p style="color: #f39c12;">工廠在台灣 ✓　但做任何重要決定都要<strong>打電話回總部</strong></p> <p>雲端服務分成兩層：(1) 資料平面（Data Plane）：實際存儲和處理資料的地方，這在台灣。(2) 控制平面（Control Plane）：管理、認證、授權、配置的地方，這通常在美國。AWS 的控制平面很多核心功能集中在 us-east-1（維吉尼亞）。GCP 的全球控制平面也有類似的集中化設計。工廠能生產，但沒有總部的授權，工廠不能開門、不能出貨、不能做任何事。</p> <h3 id="工廠在台灣但鑰匙可能在美國">工廠在台灣，但鑰匙可能在美國</h3> <p>🔑 <strong>員工要進工廠</strong>（你要登入 AWS）→ 可能要跟美國總部確認身分（IAM 驗證）→ 可能請求走海纜到維吉尼亞 → <span style="color: #e74c3c;">逾時</span></p> <p>📋 <strong>工廠要出貨</strong>（網站要更新安全憑證）→ 可能要跟美國總部簽發合約（SSL 憑證驗證）→ 請求走海纜 → <span style="color: #e74c3c;">逾時</span> → HTTPS 連線失敗</p> <p>📞 <strong>客戶要查工廠地址</strong>（DNS 解析）→ 地址簿可能在美國（Route 53 在 us-east-1）→ 查詢走海纜 → <span style="color: #e74c3c;">逾時</span> → 找不到工廠</p> <p style="color: #e74c3c;"><strong>工廠完好、原料充足、機器正常，但就是開不了門</strong></p> <p>三個具體場景說明控制平面依賴的影響：(1) IAM（Identity and Access Management），AWS 的身分驗證系統。登入 AWS Console 或 API 呼叫都需要 IAM 驗證。IAM 的核心服務在 us-east-1。海纜壅塞時，驗證請求逾時，你就登不進去。(2) SSL/TLS 憑證，HTTPS 連線需要有效的安全憑證。憑證的驗證和更新需要連到海外的 CA（Certificate Authority）或 AWS Certificate Manager（也在 us-east-1）。憑證過期無法更新 → HTTPS 連線就建不起來。(3) Route 53，AWS 的 DNS 服務。如果你的網站用 Route 53 做 DNS，你的「地址簿」就在美國。DNS 查詢逾時 → 找不到你的網站。三個場景的共同結論：你的資料和伺服器都在台灣，但「打開門的鑰匙」在美國。</p> <h3 id="你的資料就在這裡但你沒有授權打開它">你的資料就在這裡，但你沒有「授權」打開它</h3> <div style="background: rgba(231,76,60,0.1); padding: 1em; border-radius: 8px;"> <p>🔐</p> <p>你的 Google Drive 檔案可能物理上存在彰化的 GCP 機房</p> <p style="color: #e74c3c;"><strong>但你可能就是打不開</strong></p> <p style="color: #aaa;">因為你可能需要美國的伺服器來確認</p> </div> <p>這就像把<strong>保險箱放在家裡</strong>，但把鑰匙寄放在<strong>國外的銀行</strong> 🏦，銀行正常營業，但你打不了國際電話了。</p> <p>保險箱/鑰匙的比喻非常直覺：如果鑰匙不在家裡而是在國外，你不會覺得「保險箱在家就安全了」。但這正是目前大多數台灣企業的雲端架構現狀，資料在台灣，但授權機制在海外。2021 年 12 月 AWS us-east-1 大當機就是前例：其他物理上完全正常的 AWS 區域也受到影響，因為 IAM、Route 53 等控制平面服務集中在 us-east-1。那次不是海纜問題，是 us-east-1 自己出問題，但效果一模一樣：你的區域正常，但控制平面掛了，所以你也跟著掛。</p> <h3 id="雲端在台灣-安全">「雲端在台灣」≠ 安全</h3> <div style="display: flex; justify-content: center; gap: 1.5em; flex-wrap: wrap;"> <div style="flex: 1; min-width: 140px; max-width: 200px; text-align: center;"> <p style="font-size: 2.5em; margin: 0;">🏭</p> <p>工廠在台灣</p> <p style="color: #2ecc71;">✓</p> </div> <div style="flex: 1; min-width: 140px; max-width: 200px; text-align: center;"> <p style="font-size: 2.5em; margin: 0;">🔑</p> <p>鑰匙在美國</p> <p style="color: #e74c3c;">✗</p> </div> <div style="flex: 1; min-width: 140px; max-width: 200px; text-align: center;"> <p style="font-size: 2.5em; margin: 0;">📞</p> <p>電話線塞爆了</p> <p style="color: #e74c3c;">✗</p> </div> </div> <p><strong>「我們用台灣的 AWS/GCP」可能 ≠「我們的服務在對外流量大量降低時還能用」</strong></p> <p>這是雲端控制平面段落的核心結論。很多企業和政府機構在回答「你的服務有韌性嗎？」的時候，會說「我們用的是台灣的 AWS 區域」或「我們的 GCP 機房在彰化」。但這只代表「工廠在台灣」，不代表「鑰匙也在台灣」。如果控制平面依賴海外，那海纜一斷，你的服務就跟著掛。「台灣雲端」給人一種虛假的安全感，這是最需要被點破的認知誤區。</p> <h3 id="贏家真正的純國內服務">贏家：真正的純國內服務</h3> <p>在這場模擬中，可能有些服務完全不受影響。</p> <div style="background: rgba(46,204,113,0.12); padding: 1em; border-radius: 8px; text-align: left; border: 1px solid rgba(46,204,113,0.3);"> <p style="color: #2ecc71;"><strong>✅ 活下來的服務長這樣：</strong></p> <p>伺服器在台灣</p> <p>認證（Auth）在台灣</p> <p>DNS 權威伺服器在台灣</p> <p>CDN 來源站在台灣</p> </div> <p><strong>整條鏈都在島內 → 海纜斷不斷，跟它無關</strong></p> <p>這裡要強調的是：要在海纜事件中存活，不是只要「伺服器在台灣」就夠了。你的整條依賴鏈，伺服器、認證、DNS、CDN 來源，都必須在台灣。任何一個環節依賴海外，就是一個弱點。能在這場模擬中完全不受影響的服務，是那些「選擇」了把每一層都做到國內自主的服務。這不是偶然，是有意識的架構決策。</p> <h3 id="差別在哪一張表">差別在哪？一張表</h3> <table> <thead> <tr> <th> </th> <th style="text-align: center">伺服器</th> <th style="text-align: center">認證</th> <th style="text-align: center">DNS</th> <th style="text-align: center">CDN 來源</th> <th>海纜斷裂時</th> </tr> </thead> <tbody> <tr> <td><strong>純國內 stack</strong></td> <td style="text-align: center">🟢 台灣</td> <td style="text-align: center">🟢 台灣</td> <td style="text-align: center">🟢 台灣</td> <td style="text-align: center">🟢 台灣</td> <td>✅ 正常運作</td> </tr> <tr> <td><strong>台灣雲端</strong></td> <td style="text-align: center">🟢 台灣</td> <td style="text-align: center">🔴 美國</td> <td style="text-align: center">🔴 美國</td> <td style="text-align: center">🟢 台灣</td> <td>⚠️ 能跑但登不進去</td> </tr> <tr> <td><strong>完全海外</strong></td> <td style="text-align: center">🔴 海外</td> <td style="text-align: center">🔴 海外</td> <td style="text-align: center">🔴 海外</td> <td style="text-align: center">🔴 海外</td> <td>❌ 完全掛掉</td> </tr> </tbody> </table> <p>大多數台灣企業的服務落在<strong>中間那一列</strong>，看起來在台灣，但 dependency 在海外。</p> <p>這張表可以一目了然地看到三種架構的差異。重點是中間那一列，「台灣雲端」。大多數台灣企業和政府服務落在這一列：伺服器確實在台灣（AWS 台灣區域、GCP 彰化），但認證、DNS、甚至部分 CDN 邏輯依賴海外的控制平面。這給人「在台灣」的安全感，但在海纜事件中照樣出問題。這也是最危險的狀態，因為沒出事之前，沒人會去檢視這些隱藏的依賴。</p> <h3 id="是技術限制嗎">是技術限制嗎？</h3> <p>那些活下來的服務，不是運氣好，是有人<strong>選擇</strong>多花時間、多花錢、把每一層都做到國內自主。</p> <p><strong>「如果海纜斷了，我們的服務還能用嗎？」</strong></p> <p>這是本段落最重要的訊息：韌性是選擇，不是命運。AWS、GCP 的預設配置就是會依賴海外控制平面，因為它是全球化服務，這是合理的預設。但如果你在台灣經營關鍵服務，你需要主動去改這個預設。大多數企業沒有這樣做，不是做不到，是沒有人問過那個問題。這也是為什麼我們需要政策和法規來推動，因為靠企業自覺是不夠的。</p> <h2 id="模擬回顧">模擬回顧</h2> <table class="phase-table"> <thead> <tr><th>階段</th><th>你的體驗</th><th>可能的原因</th></tr> </thead> <tbody> <tr><td>0–5 分</td><td>VoIP 通話斷線</td><td>BGP reconvergence + 通話控制伺服器在日本</td></tr> <tr><td>5–30 分</td><td>全部變慢、卡住</td><td>壅塞崩潰 + 長號效應</td></tr> <tr><td>30–60 分</td><td>逐一斷線、登出</td><td>快取 TTL 到期、Token 過期、DNS 失效</td></tr> <tr><td>1–6 時</td><td>雲端後台全掛</td><td>控制平面依賴海外</td></tr> </tbody> </table> <p>這邊想再次建立完整的因果鏈：體驗 → 技術原因 → 決策者。重點是讓大家看到：沒有任何一個故障是「自然現象」，每一個都是某個組織的工程或政策選擇。</p> <h3 id="做完模擬了">做完模擬了</h3> <p>各個利害關係人需要做一次<strong>斷網演習</strong>。</p> <h3 id="-留給大家的問題">🤔 留給大家的問題</h3> <p>在剛剛的情境下，<strong>政府網站 gov.tw</strong> 撐得住嗎？<br /> <a href="http://poslab.info/slide/20260325">http://poslab.info/slide/20260325</a></p> <p>目前<strong>海底電纜還好嗎</strong>？<br /> <a href="https://drive.google.com/file/d/1n9mbFNVeukMt3g_ywP8ne9366JWWhnT5/view">https://drive.google.com/file/d/1n9mbFNVeukMt3g_ywP8ne9366JWWhnT5/view</a></p> <h2 id="延伸閱讀">延伸閱讀</h2> <p>海纜與骨幹網路的脆弱性，只是斷網情境的一半；另一半是頻寬完全歸零時的離線通訊方案。台灣開源社群過去半年投入的其中一個實作方向是 Meshtastic 與 Reticulum 之類的網狀網路：可延伸閱讀 <a href="/records/2026-04-20-kuma-academy-mesh-workshop/">Mesh 工作坊記錄</a>，以及 <a href="/records/2026-06-15-rti-meshtastic/">Rti 中央廣播電臺對台灣民間 Meshtastic 的採訪</a>。</p> <ul> <li>原始簡報連結：<a href="https://paulpengtw.github.io/crc-march-25-decks/">https://paulpengtw.github.io/crc-march-25-decks/</a></li> <li>CRC 過往記錄：<a href="/records/">/records/</a></li> <li>CRC 訊息公告：<a href="/news/">/news/</a></li> </ul> Cyborg Resilience Co-lab https://crcolab.art/events/2026-03-25-digital-resilience-forum/ 2026-03-25T00:00:00+08:00

數位韌性論壇第一場聚焦海纜議題：從「台灣海纜動態地圖」與「數位服務韌性檢測」兩個技術專案的分享出發，並從政策、社會安全與公民參與的角度，檢視地緣政治下海纜與網路基礎設施所面臨的挑戰。

<p>海纜斷光怎麼辦？海纜是不是假議題？</p> <p>連結網路的海底纜線，近期成為熱門焦點，因為被海圍繞的台灣，對於海纜的各種變化更是格外敏感、易受影響。在不穩定的地緣政治下更顯脆弱。</p> <p>報名連結：<a href="https://forms.gle/ThgUp5aVk9iiUv5u7">Google 表單</a></p> <p>只是擔心，不如來了解更多！！ { <a href="/news/2026-03-25-past-events/">數位韌性論壇</a> } 第一場，將好好來檢視海纜議題的各個面向，除了有「台灣海纜動態地圖」和「數位服務韌性檢測」」兩個技術專案的分享，讓大家實際了解我們到底要擔心海纜什麼？還將從政策、社會安全、公民參與的角度來檢視海纜的影響層面。</p> <p>CRC 團隊首次辦理的公開活動，歡迎立即報名，跟我們一起辨別問題所在，才能找到應對方式。</p> <p>ℹ️日期：3月25日（三） ℹ️時間：1:30 - 17:00（一點報到） ℹ️地點：Impact Hub 2F （臺北市中正區重慶南路三段2 號）</p> <blockquote> <p>座位有限，煩請登記報名：<a href="https://forms.gle/ThgUp5aVk9iiUv5u7">Google 表單</a></p> </blockquote> Cyborg Resilience Co-lab