為什麼需要另一種 VPN？
大多數人對 VPN 的理解停留在「加密隧道」——安裝一個 App、一鍵連線，流量就安全了。但在 2026 年，很多網路環境面對的挑戰已經不是「加密夠不夠強」，而是「你的流量看起來像不像 VPN」。
現代的深度封包檢測（DPI）系統能做到：
- TLS 指紋辨識：比對 TLS 握手中的 JA3/JA4 指紋，區分「真正的 Chrome 瀏覽器」和「偽裝成 HTTPS 的代理工具」
- 封包序列分析：用機器學習模型分析封包大小、時序特徵，辨識加密隧道
- ASN 黑名單：對已知大量部署 VPN 的雲端服務商 IP 段做分級封鎖
傳統 VPN 協議如 OpenVPN、WireGuard，在這些系統面前幾乎是透明的——握手特徵明確、封包模式固定，DPI 可以在秒級內完成辨識。
所以，這個專案的核心目標不是「更強的加密」，而是 「讓流量看起來極其平凡」。
設計思路：擬態，不是隱形
專案代號 Mimicry（擬態），靈感來自自然界的擬態偽裝——不是讓自己消失，而是讓自己看起來像環境中最普通的東西。
具體來說，整套系統疊了五層偽裝：
第一層：借用真實網站的 TLS 行為
傳統代理要自己申請 TLS 憑證，這在憑證透明度（CT Log）系統中會留下記錄——審查者只要查詢 CT Log，就能找到「哪些 IP 最近申請了憑證」，然後逐一探測。
我們用的方案（REALITY）完全不需要自己申請憑證。它「借用」一個真實大型網站的 TLS 行為——當審查者對我們的伺服器做 TLS 握手探測時，看到的回應與直接連那個大型網站完全一致。沒有可疑的自簽憑證，沒有 CT Log 記錄。
第二層：模擬真實瀏覽器指紋
TLS 握手的 ClientHello 訊息中，不同軟體的「指紋」各不相同——DPI 系統維護著一份 JA3/JA4 指紋庫，可以辨識「這個連線來自 Chrome」還是「來自某個代理工具」。
我們透過 uTLS 技術，讓客戶端發出的 TLS 握手與真實 Chrome 瀏覽器完全一致。在指紋庫中，我們的流量被歸類為「普通的 Chrome 上網」。
第三層：打亂封包特徵
即使 TLS 握手通過了，DPI 還可以分析加密流量的「統計特徵」——封包大小分布、時序間隔等。VPN 隧道的封包模式往往有別於正常瀏覽。
XTLS-Vision 技術在傳輸層對封包做 padding 與 re-framing，讓統計特徵更接近普通 HTTPS 流量，干擾機器學習分類器的判斷。
第四層：行為層面的偽裝
除了技術手段，我們也考慮了行為層面：
- 伺服器不是 24/7 只跑 VPN，平時運行正常的 Web 服務，有真實流量
- 按需啟動 VPN，使用模式更接近真實使用者行為
- 避免全時連線的「恆定隧道」特徵
第五層：基礎設施隱匿
選擇 VPS 供應商時，刻意避開「VPN 社群熱門推薦」的雲端廠商。選擇了一家歐洲本地的小型主機商，其 ASN 僅有不到 1000 個 IP，在自動化封鎖系統中幾乎不會被注意到。
實作過程
Phase 1：基礎設施
在歐洲某地開通 VPS，進行系統安全加固：
- 停用 root 遠端登入
- SSH 改為非標準埠
- 啟用防火牆，預設拒絕所有入站，僅白名單必要埠號
- 部署入侵偵測（fail2ban）
Phase 2：安裝核心引擎
安裝 Xray-core 作為代理核心，搭配 Web 管理面板。面板的安全措施包括：
- 隨機高埠 + 隨機路徑
- 強密碼認證
- 存取 IP 白名單（僅管理者可存取）
Phase 3：配置協議
設定 VLESS + REALITY + Vision 完整協議堆疊：
- 生成 x25519 金鑰對
- 配置掩體域名（選擇了一個歐洲大型科技公司的官網）
- 驗證 TLS 握手行為正確
這個階段有個重要的驗證步驟：從外部對伺服器的 443 埠做 TLS 握手，確認回傳的憑證確實是掩體域名的真實憑證，而不是任何可疑的自簽憑證。
Phase 4：客戶端配置與測試
在 Windows 上安裝 v2rayN 客戶端，匯入設定後進行測試：
- IP 檢測確認顯示為 VPS 所在地
- DNS 洩漏測試通過
- 目標網站可正常存取
- 延遲在可接受範圍內
Phase 5：運維體系
建立了運維監控框架：
- 監控腳本：定時檢測連線成功率、延遲、抖動、丟包率和 TCP RST 數量，依據四級風險（綠/黃/橙/紅）判斷是否需要介入
- 參數輪換 SOP：文件化金鑰、ShortId 輪換流程，包含客戶端同步更新步驟
- 備援規劃：設計了獨立備用節點方案，使用不同地理位置和不同掩體域名，主節點異常時可快速切換
遇到的問題與解決方案
問題一：掩體域名的選擇比想像中複雜
不是隨便找一個支援 TLS 1.3 的大站就行。測試過程中發現：
- 某些網站在特定地區會回傳 403（地區封鎖），導致 REALITY 行為異常
- 某些網站 SNI 不匹配時會洩漏預設憑證名稱，可被用來做指紋辨識
- 某些網站根路徑做 302 重導向，行為與直接存取不一致
解決方案：建立了一套掩體域名評估標準——必須支援 TLS 1.3 + H2、從 VPS 所在地存取回傳 200 OK、無地區封鎖、不洩漏預設憑證。最終選了一個從北歐存取完全自然的歐洲大型企業官網。
問題二：443 埠共用
VPS 未來需要同時跑 Web 服務和 VPN，都需要 443 埠。考慮過三種方案：
- 分埠（VPN 用非 443 埠）→ 匿蹤性大幅下降，排除
- 回落模式（Xray 判斷流量類型後轉發）→ REALITY 模式下配置複雜且不穩定
- 分時共用（用腳本切換）→ 架構最簡單，且 VPN 非 24/7 使用正好符合需求
解決方案：採用分時共用，寫了一鍵切換腳本。額外好處是平時有真實 Web 流量，強化了 IP 聲譽。
問題三：版本一致性
XTLS-Vision 對客戶端和伺服器的 Xray-core 版本有嚴格要求。版本不一致時，Vision 會靜默退化為普通 TLS，失去封包整形能力——而且不會報錯，你根本不會知道。
解決方案：在操作手冊和輪換 SOP 中都強調版本同步要求，更新伺服器時必須同步更新客戶端。
問題四：監控指標的設計
白皮書定義了四級風險等級，但實際落地時需要決定具體門檻值。太敏感會頻繁誤報，太寬鬆會錯過真正的異常。
解決方案：參考白皮書建議值作為起始點，設計了可調整的門檻參數。監控腳本支援四個指標的綜合判斷，並設計了「等級升高才通知」的邏輯，避免重複告警。
架構簡圖
用戶端 (Windows)
└─ v2rayN
└─ VLESS + REALITY + Vision (443/TCP)
│ 外觀: 正常的 HTTPS 連線到某歐洲企業官網
▼
歐洲 VPS (小型本地主機商)
└─ Xray-core → Internet
協議堆疊（由外到內）：
TCP 443 → TLS 1.3 (REALITY 掩體) → XTLS-Vision (封包整形) → VLESS → 原始流量
心得
這個專案最大的收穫是理解了一件事：在現代網路環境中，加密只是基本功，真正的挑戰是讓加密流量看起來不像加密流量。
傳統 VPN 的思維是「建一條隧道，把東西藏進去」。但當對手能辨識隧道本身的存在時，藏什麼進去已經不重要了。
Mimicry 的思維是「不要建隧道，要走正門——但讓門衛以為你是住戶」。REALITY 借用真實網站的身份、uTLS 模擬真實瀏覽器的行為、Vision 模擬正常流量的統計特徵。每一層都不是在「加密」什麼，而是在「看起來像」什麼。
這也帶出了運維的核心原則：不是讓系統固若金湯，而是讓系統在被注意到之前，已經換了一張臉。 定期輪換參數、備好替代方案、監控異常信號——這些比追求「永遠不會被發現」來得務實得多。