Zeabur 被駭之後，我們怎麼搬走 90 個服務、先換哪些金鑰

2026 年 10 月，我們用了兩年的雲端平台 Zeabur 二度被入侵，外洩範圍包含所有服務的環境變數，平台也宣布年底停止營運。我們手上大約 90 個服務，有會員系統、空間預約、LINE 機器人、金流訂閱，還有幫客戶做的網站。這篇把整個搬家過程攤開來寫：怎麼選新主機、為什麼一定要先換金鑰再搬、哪些地方差點出事。你如果也在用 Zeabur 或任何 PaaS，照著這份清單走，可以少踩很多坑。

環境變數外洩，等於整串鑰匙被拿走

外洩的不是程式碼，是鑰匙。現代網站的環境變數裡放的是資料庫密碼、金流金鑰、LINE 頻道憑證、Google 授權、AI 服務的 API key。拿到這些，對方不用破解任何東西，直接就能冒用你的身分。

所以這次搬家的第一個判斷是：搬主機只解決「平台要關」，換金鑰才解決「鑰匙已經外流」。兩件事要一起做，而且順序不能反。

我們把外洩的影響分成三種：

• 會直接變成金錢或實體損失：金流金鑰、智慧門鎖、能繞過權限讀寫整個資料庫的 service key。
• 會被拿去盜刷：OpenAI、Gemini 這類按量計費的 AI 服務。
• 會被拿去冒名：LINE 官方帳號、Discord 機器人、Meta 應用程式、Google 授權。

不是每把都一樣急。分級之後，才知道今天該先做哪一把。

新主機怎麼選：先量用量，再看價格

答案是先量。我們一開始也想直接上 AWS，後來先把每個服務實際吃多少記憶體、多少流量量出來，才發現九成服務一天的請求量很低，根本用不到大廠的彈性。

搬完之後實測，一台 4 核 8GB 跑了 11 個容器，含 2 個 PostgreSQL 和 1 個 Redis，記憶體只用不到 2GB。先量再買，省下來的錢很實在。

還有兩個做法讓我們把成本壓得更低：

• 沒在用的服務先備份再刪。我們一口氣清掉十幾個已經沒人用的專案，備份都留了雜湊值可以驗證。
• 不用 Coolify 這類管理面板，改用 Docker Compose 加一個 Caddy 自動處理 HTTPS。少一層服務，就少吃幾百 MB 記憶體。

為什麼要先換金鑰，再搬家

因為新主機不該帶著外流的鑰匙上線。如果先搬再換，等於把已經外洩的值複製一份到新家，之後還要再換一次，中間任何一步漏掉，就是一把永遠沒換到的鑰匙。

我們的做法是每個專案開一份新的設定範本：非機密設定照抄，內部自己產生的密鑰全部重新產生，外部平台的金鑰留空，到各平台後台產生新的再填進去。新值只寫進新主機和加密的本機檔案，不放回舊平台。

依風險分級的換鑰清單

換之前，先測舊金鑰還活不活

這一步省了我們很多時間。用每把舊金鑰打一次最便宜的 API（例如列出模型清單），回 401 代表早就失效，直接從設定裡刪掉就好。我們一共找到好幾把 AI 服務的 key 早已失效，帳戶餘額也是零，這些不用換，只要拿掉。

反過來也一樣。有一把以為沒在用的 Google 金鑰，後台顯示過去 8 天用了 424 次。沒先查就停用，正式站的日曆同步會當場壞掉。

試跑：先讓新容器在「不能連外」的網路裡跑起來

新主機上每個服務，我們都先放進 Docker 的 internal 網路試跑。它能開機、能連自己的資料庫，但連不到外面，所以不會誤發 LINE 訊息、不會重複扣款、不會跟舊平台搶著跑排程。

正式切換時，照這個順序走，停機可以壓到一分鐘左右：

1. 暫停舊平台上的服務，避免兩邊同時跑排程或同時登入同一個機器人。
2. 新主機先用「舊金鑰」開放連外上線，確認網站、資料庫都正常。
3. 到 LINE、金流後台把 webhook 網址改到新網域，按 Verify 確認收得到。
4. 重發各平台的 secret 與 token，換進新主機，重啟。
5. 再驗一次：LINE 的 Verify、金流送一筆測試事件、用新舊兩把 secret 各簽一次，確認新的收、舊的擋。

舊平台那份先暫停、不刪，當作回退方案。確定新家穩了再收。

真正會出事的，常常是藏起來的依賴

主程式很少出問題，出問題的是你忘了的那支小程式。我們搬完會員系統之後，辦公室門禁的同步程式還指著舊網址，連續一個半小時同步失敗。剛好那段時間沒有預約，才沒有人被關在門外。

從那次之後，每搬一個服務之前，我們都做三件事：

• 在所有機器上搜尋舊網址與舊主機 IP：伺服器、辦公室電腦、排程腳本、其他專案的設定檔都要搜。
• 查 DNS：同一個網域底下，常有其他子網域也指著舊主機。這些在舊主機到期那天會一起斷。
• 查程式碼裡寫死的網址：前端、寄信範本、API 文件裡的範例網址，都要一起換。

這三件事加起來不到半小時。漏一個，可能就是半天的事故。

網域不在自己手上，怎麼搬

有兩條路：請對方改一次 DNS 指向你控制的名稱，或者直接換一個你自己的網域。

幫客戶做的網站，網域常常在客戶自己的 Cloudflare 帳號裡。我們的做法是請客戶把子網域設成 CNAME，指向我們自己網域底下的一個「origin」名稱，再由我們把這個 origin 指到主機。這樣以後再搬家，我們改自己的紀錄就好，不用再麻煩客戶。

如果聯絡不到對方，或系統本身用的人很少，換網域反而更乾脆。換網域要一起改這些地方：

• 程式碼裡寫死的網址（開一個分支一次換完，正式分支先不動）。
• Google、Meta、TikTok 等 OAuth 的回呼網址與應用程式網域。
• 金流 webhook 網址、登入服務允許的轉址網址。
• 通知用戶新網址。舊網址失效後無法自動轉址，這是換網域唯一的代價。

第三方平台的金鑰，換法各有眉角

大部分平台都能做到「不停機換鑰」，前提是照對的順序。

Google OAuth：先加新的，停用舊的，觀察後再刪

Google 的 OAuth 用戶端可以同時有兩組 secret。先新增一組，換進所有用到的地方，再把舊的停用。停用可以隨時重新啟用，刪除就救不回來，所以我們會先停用觀察一天再刪。Google 也提醒停用要幾分鐘到幾小時才生效。

外洩的 refresh token：撤銷授權比換 secret 更有效

如果外洩的是 refresh token，攻擊者拿著它就能一直換新的存取權。最直接的作法是到 Google 帳戶的「第三方連結」把那個應用程式的授權整個移除，舊 token 立刻失效。我們實測移除後，舊 token 回傳 invalid_grant，確認作廢。

LINE、Supabase、Meta、金流 webhook

• LINE 官方帳號：channel secret 與長效 token 都在開發者後台重發。token 可以設延遲失效時間，切換當下我們選 0 小時，舊的立刻作廢。
• Supabase：新版的 secret key 可以建很多把、各自命名，建新的、切換、刪舊的，不用動資料庫的 JWT 設定。
• Meta 應用程式：先改應用程式網域、隱私權網址、OAuth 重新導向網址，再重設 App Secret。
• 金流 webhook：更新網址後重發簽章 secret，用新舊 secret 各簽一筆測試，確認程式真的有驗簽。

AI 服務：改走自己的模型池

我們把散在各專案的 OpenAI、DeepSeek 金鑰全部拿掉，改成每個專案一把通往自架模型池的專屬 key。哪個專案外洩，只要撤那一把，不會牽連別人。搬的過程中也發現有些專案設定的模型早就下架，順手一起修好。

我們自己犯過的錯

寫出來，是希望你不要再犯一次。

• 金鑰被印進紀錄。有一次從後台頁面抓資料，新產生的 secret 藏在「複製」按鈕的說明文字裡，就這樣被印出來。從此我們的工具一律預設遮蔽：抓到值就直接寫進權限 600 的檔案，畫面上只顯示欄位名稱和長度。
• 寫設定檔的引號錯了。用指令替換設定檔裡的 token 時，引號被跳脫錯，結果寫進去的是一個長度 3 的字串，兩支程式三分鐘連不上。現在寫完一定比對雜湊值，確認跟預期一致。
• 重建反向代理時，其他網站跟著斷了幾秒。同一台主機上的入口容器重建，所有網站都會短暫中斷。現在只在改網路設定時才重建，改路由一律用重新載入。
• 以為搬完了，其實還有程式指著舊網址。就是前面講的門禁同步。現在搬之前一定先全機搜尋。

搬完之後：備份、回退、收尾

搬家不是切完 DNS 就結束。我們會再做三件事：

• 每天自動備份資料庫，保留 14 天，另外加密同步一份到辦公室的機器和雲端硬碟。備份要演練還原一次，才算數。
• 舊平台的服務暫停保留，當作回退方案，確認穩定後才刪除，並申請退款與損失補償。
• 新家穩定後，回頭把舊金鑰一把一把撤銷，對照清單打勾。

下一步：你今天就可以做的三件事

1. 打開你的雲端平台，把所有服務的環境變數名稱列成一張表，依上面的分級標出「今天」「這週」「搬家時」。
2. 每把外部金鑰先打一次最便宜的 API，失效的直接刪，有效的排進換鑰順序。
3. 在所有機器上搜尋舊網址和舊主機 IP，把找到的依賴寫進清單，搬家那天逐項確認。

如果你的團隊想學著用 AI 管系統、寫自動化，像我們這次一樣讓 AI 幫忙盤點設定、比對雜湊、跑檢查，可以看看我們的實體 AI 課程，或到AI 教室許願想上的主題。想先了解各種工作怎麼用 AI，可以從10 大職業 × AI開始；企業想導入，可以看企業服務。