* 本文於太平洋時間上午 11:45 更新，以澄清此處描述的應用案例僅為概念驗證與個人專案。部分章節已進行修訂以使其更清晰易懂。
Matrix 是去中心化、端對端加密通訊的黃金標準。它為政府通訊系統、開放原始碼社群及全球注重隱私的組織提供技術核心。
然而，對個別開發人員而言，其吸引力往往更貼近日常需求：例如將分散的聊天網路（如 Discord 與 Slack）整合至單一收件匣，或單純確保您的對話歷程記錄儲存在您自己掌控的基礎架構上。從功能面來看，Matrix 的運作方式猶如一台去中心化、最終一致性的狀態機。它沒有中央伺服器推送更新，而是各個家庭伺服器 (Homeserver) 透過 HTTP 交換經過簽署的 JSON 事件，並使用衝突解決演算法，將這些事件流合併為房間歷史的統一檢視。
但維運 Matrix 是有「代價」的。傳統上，運作一台 Matrix Homeserver 意味著必須承擔沉重的維運負擔。您得佈建虛擬私人伺服器 (VPS)、針對大量寫入負載調校 PostgreSQL、管理用於快取的 Redis、設定反向代理，還得處理 TLS 憑證的輪替等瑣事。這是一頭有狀態又笨重的巨獸，無論您用量多寡，都得投入時間與金錢去「餵養」它。
我們想看看能否完全消除這種代價。
先說結論：我們做到了。在本篇文章中，我們將說明如何將 Matrix Homeserver 移植到 Cloudflare Workers 上。最終的概念驗證是一種無伺服器架構，讓維運工作近乎消失、閒置時成本可降至零，且每一筆連線預設都受到後量子加密的保護。您可以直接在 GitHub 上檢視原始碼，並部署屬於自己的執行個體。
我們的起點是 Synapse，這是一套基於 Python、為傳統部署所設計的參照 Matrix Homeserver。它使用 PostgreSQL 實現持久化儲存，使用 Redis 作為快取，並使用檔案系統儲存媒體。
要將它移植到 Cloudflare Workers，我們就得重新思考所有過去視為理所當然的儲存假設。
最大的挑戰是儲存。傳統的 Homeserver 仰賴集中式 SQL 資料庫來達成強一致性。而 Cloudflare 的 Durable Objects 提供了一個強大的替代方案。這項基元讓我們能獲得 Matrix 狀態解析所需的強一致性和原子性，同時仍允許應用程式在邊緣執行。
我們使用 Hono 框架，以 TypeScript 重寫了 Matrix 的核心通訊協定邏輯，包括事件授權、聊天室狀態解析、密碼學驗證等。使用 D1 取代 PostgreSQL，用 KV 取代 Redis，用 R2 取代檔案系統，而 Durable Objects 則負責即時協調的工作。
以下展示了各元件如何對應：
轉移到 Cloudflare Workers 為開發人員帶來多項優勢：部署簡單、成本低、延遲低，以及內建安全性。
輕鬆部署：傳統 Matrix 部署需要佈建伺服器、管理 PostgreSQL、設定 Redis 叢集、更新 TLS 憑證、設定負載平衡器、建置監控基礎架構，還得安排值班輪值人員。
而在 Workers 上，部署只需一行指令：wrangler deploy。TLS、負載平衡、DDoS 防護與全球分發全都由 Workers 自動處理。
依用量計價的成本模式：傳統 Homeserver 不管有沒有人使用，都要持續花錢。Workers 的計價方式是依請求數量計算，所以只有在使用時才需付費，當大家都休息時，成本幾乎降到零。
在全球範圍內降低延遲：部署在 us-east-1 的傳統 Matrix Homeserver，對亞洲或歐洲使用者來說，延遲至少 200 毫秒以上。而 Workers 在全球超過 300 個位置執行。當東京的使用者傳送訊息時，Worker 會直接在東京本地執行。
內建安全性：Matrix Homeserver 往往是高價值攻擊目標：它們處理加密通訊、儲存訊息歷程記錄，還負責使用者驗證。傳統部署需手動強化安全：防火牆設定、限速、DDoS 緩解、WAF 規則、IP 信譽篩選等。
Workers 預設提供上述所有安全防護。
Cloudflare 於 2022 年 10 月在所有 TLS 1.3 連線中全面部署了「後量子混合金鑰協議」。任何連線到我們 Worker 的請求，都會自動協商使用 X25519MLKEM768——這是一種混合式金鑰交換演算法，結合了經典的 X25519 與 ML-KEM（NIST 標準化的後量子密碼演算法）。
傳統密碼學仰賴一些數學難題，這些問題對傳統電腦來說極難破解，但對執行 Shor 演算法的量子電腦卻輕而易舉。ML-KEM 則是基於晶格問題，，即使在量子電腦上依然難以求解。採用混合方式意味著，只有當兩種演算法都被破解時，連線才有可能遭到入侵。
瞭解加密在何處發生，對安全架構設計至關重要。當某人透過我們的 Homeserver 傳送一則訊息時，實際流程如下：
寄件者的用戶端取得純文字訊息，並使用 Megolm（Matrix 的端對端加密）對其進行加密。這個加密後的負載接著被包裹在 TLS 中進行傳輸。在 Cloudflare 上，該 TLS 連線使用 X25519MLKEM768，使其具備抗量子能力。
Worker 會終止 TLS 連線，但它接收到的內容仍然是加密的——即 Megolm 密文。我們將此密文儲存在 D1 資料庫中，依照聊天室和時間戳記進行索引，並將其遞送給接收者。但我們從未看見純文字。訊息「Hello, world」只存在於寄件者的裝置與接收者的裝置上。
當接收者進行同步時，流程反向進行。他們透過另一條抗量子的 TLS 連線接收加密負載，然後在本機使用他們的 Megolm 工作階段金鑰進行解密。
此機制透過兩層獨立運作的加密提供保護：
傳輸層 (TLS) 保護傳輸中的資料。它在用戶端加密，並在 Cloudflare 邊緣解密。透過 X25519MLKEM768，該層現已具備後量子安全性。
應用程式層 (Megolm E2EE) 保護訊息內容。它在寄件者的裝置上加密，且僅在接收者的裝置上解密。該層使用傳統的 Curve25519 密碼學。
任何 Matrix Homeserver 的營運者，不論是在 VPS 上執行 Synapse，還是使用我們在 Workers 上的實作，都能看到中繼資料：例如有哪些聊天室、誰在裡面、訊息的傳送時間等等。但基礎架構鏈中的任何一方都無法看到訊息內容，因為端對端加密的資料負載在進入網路之前，就已於寄件者的裝置上加密了。Cloudflare 終止 TLS 連線並將請求傳遞給您的 Worker，但這兩者都只看到 Megolm 密文。加密聊天室中的媒體在上傳前已於用戶端側加密，而私密金鑰從未離開使用者的裝置。
若要在傳統 Matrix 部署中啟用後量子 TLS，您需要：將 OpenSSL 或 BoringSSL 升級到支援 ML-KEM 的版本；正確設定密碼套件偏好；測試所有 Matrix 應用程式的用戶端相容性；監控 TLS 協商失敗的情況；持續追蹤 PQC 標準的演進妥；善處理不支援 PQC 的用戶端。
而使用 Workers，這一切都是「自動生效」的。Chrome、Firefox 和 Edge 都已支援 X25519MLKEM768。使用平台 TLS 堆疊的行動應用程式也會自動繼承這項支援。隨著 Cloudflare 持續擴展其 PQC 部署，安全狀態也會自動提升，而且我們無需採取任何行動。
在移植 Tuwunel 過程中，我們領悟到的關鍵點是：不同資料需要不同的「一致性」保證。我們讓每個 Cloudflare 基元都發揮其最擅長的功能。
D1 負責儲存需要在重啟後仍留存且需支援查詢的所有資料，例如使用者、聊天室、事件、裝置金鑰等。整套 Matrix 資料模型共用了超過 25 張資料表。
CREATE TABLE events (
event_id TEXT PRIMARY KEY,
room_id TEXT NOT NULL,
sender TEXT NOT NULL,
event_type TEXT NOT NULL,
state_key TEXT,
content TEXT NOT NULL,
origin_server_ts INTEGER NOT NULL,
depth INTEGER NOT NULL
);
D1 基於 SQLite，意味著我們只需極少改動就能移植 Tuwunel 的查詢。JOIN、索引與彙總操作都能正常運作。
我們吸取了一個慘痛的教訓：D1 的最終一致性打破了外鍵限制。當後續對事件的寫入檢查外鍵時，對聊天室的寫入可能不可見。我們移除了所有外鍵，並在應用程式碼中強制執行參照完整性。
OAuth 授權碼的有效期為 10 分鐘，而重新整理權杖則在整個工作階段內有效。
// Store OAuth code with 10-minute TTL
kv.put(&format!("oauth_code:{}", code), &token_data)?
.expiration_ttl(600)
.execute()
.await?;
KV 的全球分佈特性，意味著無論使用者身在何處，OAuth 流程都能快速運作。
Matrix 的媒體檔案可直接對應到 R2：上傳一張影像後，會得到一個內容定址 URL，而且無需輸出費用。
有些操作無法接受「最終一致性」，例如當用戶端申領一次性加密金鑰時，該金鑰必須被原子性地移除。如果兩個用戶端同時嘗試申領同一個金鑰，就會造成加密工作階段建立失敗。
Durable Objects 提供單執行緒、強一致性的儲存：
#[durable_object]
pub struct UserKeysObject {
state: State,
env: Env,
}
impl UserKeysObject {
async fn claim_otk(&self, algorithm: &str) -> Result<Option<Key>> {
// Atomic within single DO - no race conditions possible
let mut keys: Vec<Key> = self.state.storage()
.get("one_time_keys")
.await
.ok()
.flatten()
.unwrap_or_default();
if let Some(idx) = keys.iter().position(|k| k.algorithm == algorithm) {
let key = keys.remove(idx);
self.state.storage().put("one_time_keys", &keys).await?;
return Ok(Some(key));
}
Ok(None)
}
}
我們將 UserKeysObject 用於端對端加密的金鑰管理，將 RoomObject 用於即時聊天室事件（如正在輸入指示和已讀回條），將 UserSyncObject 用於裝置對裝置的訊息佇列。其餘的流程則透過 D1 處理。
我們的實作支援完整的 Matrix E2EE 堆疊：裝置金鑰、跨裝置簽署金鑰、單次金鑰、備用金鑰、金鑰備份以及脫水裝置。
現代 Matrix 用戶端採用 OAuth 2.0/OIDC，而非舊式的密碼登入流程。我們實作了一個完整的 OAuth 提供者，包含動態用戶端註冊、PKCE 授權、RS256 簽署的 JWT 權杖、支援輪替的權杖更新機制，以及標準的 OIDC 探索端點。
curl https://matrix.example.com/.well-known/openid-configuration
{
"issuer": "https://matrix.example.com",
"authorization_endpoint": "https://matrix.example.com/oauth/authorize",
"token_endpoint": "https://matrix.example.com/oauth/token",
"jwks_uri": "https://matrix.example.com/.well-known/jwks.json"
}
將 Element 或任何 Matrix 用戶端指向您的網域，它就能自動探索所有設定。
傳統的 Matrix 同步機制會在初始連線時傳輸數 MB 的資料，消耗行動裝置的電量與流量。
Sliding Sync 讓用戶端只請求需要的資料。初始同步僅取得最近 20 個聊天室的基本狀態，使用者捲動時才逐步請求更多範圍。伺服器會追蹤位置，並僅推送變更部分 (deltas)。
結合邊緣執行，即使在緩慢的網路環境下，行動用戶端也能在 500 毫秒內完成連線並顯示聊天室清單。
對於為小型團隊提供服務的 Homeserver：
| 過去 (VPS) | Workers |
|---|
每月費用（閒置） | $20-50 | <$1 |
每月費用（作用中） | $20-50 | $3-10 |
全球延遲 | 100-300ms | 20-50ms |
部署時間 | 小時 | 幾秒鐘 |
維護 | 每週一次 | 無 |
DDoS 防護 | 額外的費用 | 已內含 |
後量子 TLS | 設定複雜 | 自動 |
*基於截至 2026 年 1 月 15 日，DigitalOcean、AWS Lightsail 及 Linode 等服務公開的費率與指標。
在擴展規模時，經濟效益更為顯著。傳統部署需要容量規劃與過度佈建，而 Workers 會自動擴展。
我們最初只是實驗：Matrix 能在 Workers 上執行嗎？結果證明，不僅可以，這套方法也適用於其他具狀態的通訊協定。
透過將傳統的具狀態元件對應到 Cloudflare 的基礎元件：Postgres 對應 D1、Redis 對應 KV、互斥鎖對應 Durable Objects，我們發現複雜的應用程式並不需要複雜的基礎架構。我們移除了作業系統、資料庫管理和網路設定的負擔，只留下應用程式邏輯與資料本身。
Workers 讓您擁有資料主權，卻不必承擔基礎架構的負擔。
我目前仍在積極實驗這套實作，並熱切歡迎任何對此類服務感興趣的朋友貢獻心力。
準備好使用 Workers 建構強大的即時應用程式了嗎？立即開始使用 Cloudflare Workers，並探索 Durable Objects 以打造您自己的具狀態邊緣應用程式。加入我們的 Discord 社群，與其他在邊緣建置的開發人員交流。