基礎設施

上一篇講了 Xray REALITY 服務端的部署。這篇專門講客戶端配置——收集到各平臺的使用者名稱、伺服器地址、公鑰等資訊後，怎麼在不同客戶端裡配置。 你需要準備好以下資訊（從服務端配置裡獲取）： 引數 說明 伺服器地址 VPS 的公網 IP 埠 服務端監聽的埠（推薦 443） UUID 服務端配置的 client id Public Key xray x25519 生成的公鑰 Short ID 服務端配置的 shortIds 之一 SNI 服務端配置的 serverNames（如 www.apple.com） mihomo（Clash Meta） mihomo 原生支援 REALITY，配置放在 proxies: 節點： proxies: - name: "us-reality" type: vless server: 你的VPS_IP port: 443 uuid: 你的UUID network: tcp tls: true udp: true flow: xtls-rprx-vision reality-opts: public-key: 你的公鑰 short-id: "55470656" servername: www.apple.com client-fingerprint: chrome 引數說明 client-fingerprint：客戶端 TLS 指紋偽裝，推薦選項： ...

最近一年用 AI 工具碰到一個高頻問題：機場的共享節點 IP 被 AI 平臺標記，登入時要求驗證、限制功能、甚至封號。根本原因是這些 IP 被太多人用過，平臺的風控系統認為是"異常流量"。 解決方案：用住宅 IP作為出口。住宅 IP 來自真實家庭寬頻，對平臺來說跟普通使用者一樣，透過率高得多。 這篇文章講怎麼在 mihomo（原 Clash Meta）裡配置住宅 IP 出口，以 IPRoyal 為例。 住宅 IP 和機場節點的區別 對比 機場節點（VPS） 住宅代理 IP IP 型別 資料中心 IP 真實家庭寬頻 IP 被風控機率 高（共享 IP，大量請求） 低（看起來像真實使用者） 速度 快（專線） 中等 價格 按月訂閱，便宜 按 GB 計費，貴一些 適合場景 日常瀏覽、流媒體 AI 工具、賬號註冊、資料採集 住宅 IP 不適合替代機場做所有流量，太貴了。正確用法是：只讓需要住宅 IP 的流量走住宅代理，其餘走正常節點。 IPRoyal 住宅 IP 配置 我用的是 IPRoyal，按 GB 計費，用多少買多少，不需要月付，質量穩定。 ...

Hysteria2 基於 QUIC 協議（UDP），理論上在高延遲、高丟包網路裡比 TCP 類協議快得多。但很多人部署完發現速度一般，原因通常是頻寬引數沒配對或者擁塞控制演算法沒選對。 這篇文章專門講調優。假設你已經跑通了基礎部署（參考 Hysteria2 搭建教程），現在想把速度榨出來。 頻寬引數：最影響速度的配置 Hysteria2 的頻寬引數控制著它的傳送速率，沒配或配錯是速度差的最常見原因。 服務端 bandwidth /etc/hysteria/config.yaml： bandwidth: up: 1 gbps # 服務端上行（客戶端下載方向） down: 1 gbps # 服務端下行（客戶端上傳方向） 這裡填的是服務端（VPS）的實際頻寬上限，不是你家寬頻的速度。 常見 VPS 頻寬： DMIT HK/US Premium：1 Gbps 埠，但共享，實際峰值 200-500 Mbps AWS t3 型別：5-25 Gbps（burst） 低價 VPS：通常 100-500 Mbps 怎麼測 VPS 實際頻寬： # 在 VPS 上安裝 speedtest curl -s https://packagecloud.io/install/repositories/ookla/speedtest-cli/script.deb.sh | bash apt install speedtest-cli -y speedtest 根據測速結果填頻寬值。 ...

用代理節點訪問 Claude、ChatGPT 時，可能遇到過這些情況： 登入時反覆彈出驗證碼 賬號被提示"unusual activity" 某些功能被悄悄限制 API 呼叫穩定性差，偶爾 403 這些問題的根源通常不是代理協議，而是出口 IP 的質量。 IP 質量的分類 網際網路上的 IP 地址大致分為三類，對應不同的"可信度"： 住宅 IP（Residential IP） 由 ISP（電信、聯通等）分配給普通家庭寬頻使用者 使用場景：正常家庭上網 被 AI 服務認為是真實使用者 資料中心 IP（Datacenter IP） AWS、GCP、Azure、Vultr、DigitalOcean 等雲廠商的 IP 段 這些 IP 段是公開已知的，任何服務都可以查詢某個 IP 是否屬於雲服務商 特徵明顯：大量不同賬號從同一 /24 網段訪問 代理/VPN IP 商業代理服務的 IP 池 被高強度使用，信譽最差 AI 服務的風控邏輯 AI 服務的風控通常不是簡單的"封 IP"，而是基於 IP 質量做差異化對待： 請求進來 → IP 質量檢查 ├─ 住宅 IP → 正常處理 ├─ 資料中心 IP → 提高 CAPTCHA 頻率 / 限制某些功能 └─ 已知代理 IP → 拒絕 / 要求重新驗證 這就是為什麼即使你的節點"能連上"，使用體驗也可能很差：功能在降級執行，不是完全封鎖。 ...

用 DMIT 這類付費 VPS 搭代理節點，穩定性好但有成本。很多人不知道，Cloudflare Workers 有每天 10 萬次的免費請求額度，可以用來跑一個完全零成本的 VLESS 節點——作為備用或平替方案，值得每人都部署一個。 本文用的是開源專案 edgetunnel，部署過程 10 分鐘以內完成。 原理簡介 Cloudflare Workers 是執行在 CF 邊緣節點的 JavaScript 函式。edgetunnel 把 VLESS 協議實現在 Worker 裡，流量經過 CF 的 CDN 網路中轉，繞開直接 IP 識別。 優點： 完全免費（免費計劃每天 10 萬次請求，足夠個人使用） 無需伺服器，不存在 IP 被封問題 CF 的 IP 段被封機率極低 侷限： 速度受 CF 網路質量影響，高峰期不如專線 VPS 不適合大流量下載，適合日常瀏覽和輕量使用 部分地區對 CF IP 有 QoS 前置準備 一個 Cloudflare 賬號（免費註冊） 一個域名（可選，但推薦，CF 免費提供 workers.dev 子域名也行） 部署步驟 第一步：Fork 專案到你的 GitHub 開啟 https://github.com/cmliu/edgetunnel，點右上角 Fork，複製到自己的賬號。 ...

跑著量化策略和代理節點的伺服器，沒有監控是非常危險的。凌晨記憶體爆了、磁碟滿了、策略掛了——如果沒有告警，可能幾個小時後才發現。 這篇文章從零開始，搭建一套完整的監控系統：被監控機器上跑 Node Exporter 採集指標，Prometheus 收集儲存，Grafana 視覺化展示，加上 Telegram 告警。 架構說明 被監控 VPS（N臺） 監控中心 VPS（1臺） ┌──────────────┐ ┌─────────────────────┐ │ Node Exporter │ ──9100→ │ Prometheus（採集） │ │ Node Exporter │ ──9100→ │ Grafana（展示） │ │ Node Exporter │ ──9100→ │ Alertmanager（告警） │ └──────────────┘ └─────────────────────┘ 我的做法：一臺小 VPS（1核1G 足夠）作為監控中心，其他機器裝 Node Exporter 暴露指標。 第一步：在被監控機器上安裝 Node Exporter 每臺要監控的 VPS 都要做這一步。 # 下載 Node Exporter（確認最新版本號） cd /tmp wget https://github.com/prometheus/node_exporter/releases/download/v1.8.2/node_exporter-1.8.2.linux-amd64.tar.gz tar xzf node_exporter-1.8.2.linux-amd64.tar.gz mv node_exporter-1.8.2.linux-amd64/node_exporter /usr/local/bin/ 建立 systemd 服務： ...

家庭網路多閘道器架構那篇文章講了整體架構，但規則怎麼寫沒有細說。這篇單獨講 mihomo 的分流規則，從語法基礎到實用配置模板，逐步拆解。 規則的基本概念 mihomo 的流量分流透過 rules 欄位控制，每條規則的格式： 規則型別,匹配值,策略組 比如： rules: - DOMAIN-SUFFIX,google.com,代理 - IP-CIDR,192.168.0.0/16,DIRECT - GEOIP,CN,DIRECT - MATCH,代理 # 兜底規則，匹配所有剩餘流量 規則按順序匹配，第一條命中即執行，後面的不再判斷。 順序非常重要。 規則型別詳解 域名類規則 # 精確匹配域名 - DOMAIN,www.google.com,代理 # 匹配域名及其所有子域名（最常用） - DOMAIN-SUFFIX,google.com,代理 # 覆蓋：google.com / mail.google.com / api.google.com # 域名關鍵詞（效能較差，少用） - DOMAIN-KEYWORD,google,代理 # 匹配任何包含 "google" 的域名 # 正規表示式（最靈活，但最慢） - DOMAIN-REGEX,^.*\.google\.com$,代理 優先順序建議： DOMAIN > DOMAIN-SUFFIX > DOMAIN-KEYWORD 越精確的規則放越前面，效能更好，也避免誤匹配。 IP 類規則 # IPv4 CIDR - IP-CIDR,192.168.0.0/16,DIRECT - IP-CIDR,10.0.0.0/8,DIRECT - IP-CIDR,172.16.0.0/12,DIRECT # IPv6 CIDR - IP-CIDR6,::1/128,DIRECT # 注意：IP-CIDR 會觸發 DNS 解析，對純域名規則之前的流量有效能影響 # 建議加 no-resolve 字尾，跳過 DNS 解析直接匹配連線 IP - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve GeoIP 規則 根據 IP 所屬國家分流： ...

很多人以為有了 VPS 代理節點就夠了，其實不然。VPS 的 IP 來自資料中心，很多平臺會針對資料中心 IP 做額外限制——OpenAI 不讓資料中心 IP 註冊、某些平臺觸發額外驗證、賬號因"異常登入"被限制……這些場景需要住宅 IP。 IPRoyal 是我長期在用的住宅 IP 服務，這篇文章說清楚什麼時候需要住宅 IP，以及怎麼用。 住宅 IP vs 資料中心 IP 對比項 資料中心 IP（VPS） 住宅 IP 來源 AWS、Google Cloud 等雲服務商 真實家庭寬頻 ISP 識別難度 容易被平臺檢測 極難區分（看起來就是普通使用者） 速度 快，穩定 因 ISP 而異，可能有波動 價格 低（月付固定） 高（按流量 GB 計費） 適合用途 日常代理 需要"像真人"的操作 資料中心 IP 的 ASN（自治系統號）是已知的，Cloudflare、Google 等公司維護了這些 IP 段的黑名單。住宅 IP 的 ASN 是各地 ISP（中國移動、Comcast、Vodafone 等），和普通家庭使用者沒有區別。 ...

DMIT 是我主力在用的 VPS 服務商，用了一年多。它的香港和美國節點在連線速度和穩定性上是我用過最好的，IP 被封機率也低。 很多人看到 DMIT 的介面是英文，不知道怎麼買，這篇文章把流程完整走一遍。 為什麼選 DMIT 選 VPS 的核心看三點：延遲、穩定性、IP 質量。 DMIT 的優勢： 香港節點對國內延遲極低（廣州通常 20-40ms） 使用 CN2 GIA 線路，國內三網直連 原生 IP，流媒體解鎖能力強（Netflix、Disney+ 香港區） 支援 Hysteria2，UDP 效能好 IP 被封機率明顯低於普通 BGP 線路 劣勢： 價格偏高（香港節點月費 $14.9 起） 熱門套餐經常缺貨 詳細和其他服務商的對比：VPS 選購指南 第一步：註冊賬號 訪問 DMIT 官網。 點右上角 Register 填寫資訊： First Name / Last Name：填真實姓名（用於賬單） Email Address：常用郵箱 Password：設定強密碼 點 Register 完成註冊 去郵箱驗證郵件（有時在垃圾郵件資料夾裡） 註冊完成後自動登入到控制面板（Client Area）。 ...

Hysteria2 是一個基於 QUIC 協議（UDP）的代理工具，在高丟包、高延遲網路下表現遠超 TCP 協議。它和 VLESS+XTLS-Reality 形成互補：TCP 受限時用 Hysteria2，UDP 受限時用 VLESS+Reality，兩個協議搭配部署是目前最穩的方案。 為什麼選 Hysteria2 核心優勢： 基於 QUIC/UDP，在高丟包網路下仍有較好速度表現 內建頻寬偽裝，流量特徵更難被精準識別 配置簡單，比 Xray 輕量 mihomo（Clash Meta）原生支援 適用場景： 場景 推薦協議 TCP 被 QoS 限速 Hysteria2 ✓ UDP 被封 VLESS+XTLS 日常使用（兩個都有） mihomo 自動切換 前置準備 一臺海外 VPS，推薦 DMIT（支援 Hysteria2 的 UDP 流量） Ubuntu 22.04+ 一個域名（可選，用自簽證書也可以） 服務端部署 安裝 Hysteria2 bash <(curl -fsSL https://get.hy2.sh/) 安裝完成後，程式位於 /usr/local/bin/hysteria，systemd 服務名為 hysteria-server。 生成自簽證書 不需要域名的情況下，用自簽證書： ...

Xray 的 VLESS+XTLS-Reality 是目前公認抗封鎖能力最強的協議組合。它的核心原理是流量偽裝成正常的 TLS 握手，讓 GFW 難以透過特徵識別判斷是代理流量。 這篇文章從零開始，完整部署一套可用的配置。 前置準備 一臺海外 VPS（推薦 DMIT 香港或美國節點，線路質量好） VPS 系統：Ubuntu 22.04+ 本地客戶端：mihomo（原 Clash Meta） 服務端部署 安裝 Xray bash -c "$(curl -L https://github.com/XTLS/Xray-install/raw/main/install-release.sh)" @ install 生成 XTLS-Reality 所需金鑰 xray x25519 輸出類似： Private key: 你的私鑰（儲存好） Public key: 你的公鑰（填入客戶端配置） 再生成 UUID： xray uuid 服務端配置檔案 /usr/local/etc/xray/config.json： { "inbounds": [ { "port": 443, "protocol": "vless", "settings": { "clients": [ { "id": "你的UUID", "flow": "xtls-rprx-vision" } ], "decryption": "none" }, "streamSettings": { "network": "tcp", "security": "reality", "realitySettings": { "show": false, "dest": "www.apple.com:443", "xver": 0, "serverNames": ["www.apple.com"], "privateKey": "你的私鑰", "shortIds": [""] } }, "sniffing": { "enabled": true, "destOverride": ["http", "tls", "quic"] } } ], "outbounds": [ {"protocol": "freedom", "tag": "direct"}, {"protocol": "blackhole", "tag": "block"} ] } 關鍵引數說明： ...

IP 被封是代理節點的常見問題，處理過很多次了，這篇文章寫下完整的應對流程。 第一步：確認是 IP 被封還是其他問題 連不上節點時，先排除非封鎖原因： # 從國內測試 IP 連通性（用手機熱點，排除本地網路問題） ping 你的VPS_IP # 測試埠是否通 nc -z -w5 你的VPS_IP 443 && echo "open" || echo "blocked" 常見混淆情況： 現象 可能原因 ping 不通，但 SSH 能連 協議被識別，埠被封 SSH 也連不上 IP 被完全封鎖，或 VPS 宕機 能 ping 通，但連線慢 線路擁塞，不是封鎖 只有晚高峰斷 QoS 限速，不是封鎖 驗證 IP 是否被牆的最快方法：用國內網路和海外網路分別 ping，海外能 ping 國內不行 = 被牆。 線上工具：ping.pe，輸入 IP 從多個國家測試連通性。 第二步：應急切換 如果有備用節點 這是最重要的一課：永遠不要只有一個節點。 我的 mihomo 配置了自動故障切換： proxy-groups: - name: "自動選擇" type: fallback # 有節點掛了自動切換 url: http://www.gstatic.com/generate_204 interval: 30 proxies: - DMIT-HK - DMIT-US - 騰訊雲-JP 主節點被封后 30 秒內自動切到備用，使用者無感知。 ...