先釐清機場訂閱與 Clash 的關係
「Clash 機場訂閱」通常是第三方代理服務提供的遠端訂閱連結，內容可能包含多個代理節點、策略組、分流規則與 DNS 設定。Clash Verge、Clash Verge Rev、Clash for Android 或其他支援 mihomo 核心的客戶端，負責匯入、解析並套用這份設定；客戶端本身不等於訂閱服務，訂閱服務也不一定代表某一款特定軟體。
因此，挑選機場時不能只看「節點數量」或宣傳頁上的最高速度。節點數量很多，可能只是同一批出口分布在不同連接埠；標示支援 Clash，也不代表設定一定適合目前使用的核心版本。較穩妥的判斷方式，是同時檢查服務的連線品質、流量限制、協定相容性、更新方式、退款規則與隱私說明。
| 評估面向 | 要查看的內容 | 常見風險 |
|---|---|---|
| 速度 | 不同時段的延遲、下載速度與尖峰表現 | 只展示單次或本地測試結果 |
| 穩定性 | 斷線率、節點壽命、故障公告與維護紀錄 | 節點頻繁消失，卻沒有通知或替代方案 |
| 流量方案 | 每月流量、重置日期、超量處理與倍率計算 | 低價方案其實有高倍率或隱藏限制 |
| 協定相容性 | Clash、mihomo、TLS、WebSocket、Reality 等支援範圍 | 只提供模糊的「全平台支援」說法 |
| 售後保障 | 付款方式、客服管道、退款條件及服務狀態頁 | 只使用私人帳號收款，無清楚服務條款 |
速度不能只看標稱頻寬
代理速度受到本地網路、節點出口、跨境路由、遠端伺服器負載與目標網站限制共同影響。服務商宣稱的「千兆速度」通常只是節點網卡或機房線路的理論上限，不代表單一使用者在晚上尖峰時段就能得到相同結果。對一般瀏覽、視訊會議、程式套件下載與影音串流而言，延遲、抖動和丟包率往往比最高下載數字更重要。
比較時至少應測試三類目標：第一類是距離較近的測速站，用來觀察本地到節點的基本延遲；第二類是實際常用的網站或服務，用來確認跨網路路由是否穩定；第三類是長時間下載或視訊播放，用來觀察速度是否在數分鐘後下降。只在白天測一次，無法代表晚間多人使用時的表現。
建立可重複的測試條件
測試前先固定裝置、網路連線、客戶端模式與 DNS 設定。不要一邊使用 Wi-Fi、一邊切換行動網路，也不要在不同測試中混用 TUN、系統代理與瀏覽器外掛。可以選擇三至五個候選節點，在上午、晚間和週末各測一次，記錄延遲、下載速度、上傳速度、連線是否中斷以及實際出口位置。
- 延遲：適合觀察互動反應，數值較低通常較好，但不能單獨代表下載速度。
- 抖動：延遲忽高忽低時，語音、視訊和遠端桌面容易出現卡頓。
- 丟包：少量丟包也可能造成 TCP 重傳、網頁載入變慢或連線反覆重建。
- 持續吞吐：觀察連續下載十至十五分鐘的速度曲線，不要只記錄開始幾秒的峰值。
- 尖峰表現：晚間使用量增加時仍能維持基本可用，通常比白天的最高速更有參考價值。
如果節點可以測速，但常用網站無法開啟，問題未必是頻寬不足，也可能是出口 IP 被目標服務限制、DNS 解析結果不合適，或訂閱中的規則將網域錯誤地分流至直連。測試時應在 Clash 的連線與日誌頁查看實際命中的策略，不要只依照網頁能否開啟下結論。
穩定性要看節點與服務管理
穩定性包含兩個層面：節點本身是否能長時間建立連線，以及訂閱服務是否能持續維護設定。前者與伺服器負載、出口品質、傳輸協定和網路路由有關；後者則與節點替換、域名變更、流量統計、訂閱更新及故障通知有關。只有節點很多，並不能證明服務穩定。
觀察服務商是否提供公開的維護公告、狀態頁或明確的客服規則。正常維護不一定是問題，重點在於是否提前通知、是否提供替代節點，以及故障後是否能說明原因。若服務頻繁更換域名、訂閱連結沒有任何解釋，或客服只回覆「稍後恢復」，就應提高警覺。
| 現象 | 可能原因 | 判斷方式 |
|---|---|---|
| 只有一個地區的節點全部失效 | 區域路由、伺服器維護或出口封鎖 | 比較其他地區節點及服務公告 |
| 所有節點同時無法連線 | 訂閱域名、帳戶狀態或服務端故障 | 重新更新訂閱並查看 HTTP 回應 |
| 連線成功但速度持續下降 | 尖峰限速、共享出口過載或流量倍率 | 在不同時段測試同一節點 |
| 節點名稱存在但核心啟動失敗 | 設定語法、協定欄位或核心版本不相容 | 查看 mihomo 日誌中的 parse 或 unsupported 訊息 |
流量方案與實際成本怎麼算
比較價格時不能只看每月標價，還要確認流量重置週期、流量倍率、同時連線數、速度限制與未用流量是否保留。有些方案按不同節點或協定計算倍率，例如經過特定線路時消耗兩倍或更高流量；也有服務將影音、遊戲或高頻寬用途列入不同的使用規則。這些條款若沒有在付款前說明，低價方案可能反而更快用完。
可以用「每月可用流量 ÷ 月費」計算表面單價，再用實際消耗估算真實成本。假設每月觀看影音、更新軟體和一般瀏覽合計使用 300 GB，就不應只拿 100 GB 方案的價格比較。若方案提供短期、月付、季付和年付，第一次使用宜選擇週期較短的方案，先驗證晚間穩定性與客服反應，再考慮長期付款。
- 確認流量是每月自動重置，還是從購買日起計算。
- 確認下載與上傳是否合併計算，以及是否存在節點倍率。
- 確認同一帳戶可以在幾台裝置使用，是否限制同時連線數。
- 確認超量後是停止服務、降速、額外購買，還是自動扣款。
- 確認退款期限的起算點，以及更新訂閱後是否仍可退款。
動手檢查訂閱與客戶端相容性
付款前若能使用試用方案，建議先做一次完整的匯入與更新測試。不要直接把訂閱連結貼到不明網站轉換，因為訂閱網址通常包含帳戶識別資訊，外洩後可能被他人使用或轉發。優先在本機 Clash 客戶端中加入設定，並確認服務商提供的連結使用 HTTPS。
- 在客戶端的「設定」或「Profiles」頁新增訂閱，輸入服務商提供的訂閱 URL。
- 先執行一次更新，確認回應狀態為成功，並查看更新時間與設定檔大小是否合理。
- 開啟設定檔，確認是否建立代理節點、策略組、規則與必要的 DNS 欄位。
- 進入代理頁，選擇一個延遲較低的節點，先以系統代理測試一般瀏覽。
- 查看連線頁與日誌頁，確認要求確實命中預期策略，而不是全部走 DIRECT。
- 若需要 TUN，再確認客戶端權限、虛擬網卡與 DNS 設定，避免一開始就把所有變因同時開啟。
mixed-port: 7890
mode: rule
allow-lan: false
log-level: info
external-controller: 127.0.0.1:9090上面的欄位只是本機測試時常見的基礎參數，不是所有訂閱都會使用相同連接埠。訂閱匯入後若出現 YAML 解析錯誤、策略組指向不存在的節點，或核心提示不支援某種代理類型，應先保存錯誤訊息，再向服務商確認支援的 Clash 或 mihomo 版本。不要為了讓設定勉強啟動而刪除未知欄位，因為那可能改變 DNS、規則或安全設定。
協定、隱私與付款安全不能忽略
常見訂閱可能包含 Shadowsocks、VMess、Trojan、Hysteria2 或其他 mihomo 支援的代理類型。不同協定在延遲、抗丟包能力、CPU 負載與網路環境適應性上各有差異，不能單純以名稱判斷安全或速度。重要的是目前使用的 Clash 或 mihomo 核心是否支援該協定、設定欄位是否完整，以及服務商是否清楚說明憑證、TLS、SNI、傳輸方式與 UDP 支援。
「加密」也不等於服務商完全看不到使用資訊。代理服務通常仍可能取得連線時間、流量大小、來源 IP 或帳戶識別資料，實際保留內容取決於服務商的系統與隱私政策。挑選時應查看是否公開資料保存期限、是否記錄 DNS 查詢、是否將資料交給第三方，以及帳戶刪除後如何處理資料。沒有任何隱私說明，或只用「絕對匿名」作為宣傳口號，並不能構成可信的安全保證。
- 訂閱連結應妥善保管，不要公開貼到論壇、截圖或線上轉換工具。
- 帳戶使用獨立密碼，付款平台不要與重要服務共用登入憑證。
- 優先選擇有正式付款頁、服務條款、退款政策與客服紀錄的服務。
- 避免要求安裝來源不明的客戶端、根憑證、系統服務或遠端控制工具。
- 不要因為某個節點能開啟特定網站，就推定該服務沒有記錄或完全安全。
付款前的機場避雷清單
最後可以把候選服務放進一張簡單的評估表，而不是被單一優惠價格或節點數量影響。可靠的服務未必是最便宜，也未必擁有最多節點；更重要的是條款清楚、測試結果可重複、故障時有人處理，並且能在目前使用的客戶端中正常更新。
| 付款前問題 | 較合理的答案 | 需要謹慎的訊號 |
|---|---|---|
| 是否提供試用或短週期方案 | 可以先用低成本驗證速度與穩定性 | 強迫一次購買半年或一年 |
| 服務中斷怎麼處理 | 有公告、客服與替代方案 | 沒有狀態資訊，也不說明修復時間 |
| 流量如何計算 | 倍率、重置日與超量規則寫得清楚 | 只寫「不限速」卻不說流量上限 |
| 是否支援 mihomo | 列出相容核心、協定與更新方式 | 只宣稱全平台，沒有技術細節 |
| 是否可以退款 | 退款條件、期限與申請方式明確 | 付款後才告知不可退款 |
如果服務商要求你停用防毒軟體、匯入不明根憑證、執行遠端指令，或提供與代理無關的系統權限，應立即停止操作。訂閱本身通常只需要在 Clash 客戶端中加入 URL，不應要求使用者交出作業系統密碼、瀏覽器 Cookie 或其他私人資料。遇到節點失效時，也先從客戶端日誌和服務公告判斷，不要下載來路不明的「修復工具」。