Mihomo

跑 Binance 量化策略最怕 “IP 被限制”——訪問合約 API 突然返回 451 Unavailable。AWS/GCP 等雲服務商的 IP 段被大部分交易所拉黑，機房 IP 也時不時被風控。這篇講我搭的一套穩定量化代理鏈：DMIT 香港 VPS 做穩定跳板 + IPRoyal 住宅 IP 做最終出口 + Claude 做監控切換。 問題本質 Binance（以及大部分大交易所）的 IP 封鎖邏輯： 機房 IP 段：AWS/GCP/OVH/DO → 直接 451 不讓訪問合約 API VPN 節點：流量特徵明顯 → 有機率封號 Shared Proxy：被其他使用者濫用過 → 拉黑 住宅 IP（ISP 分配給家庭使用者）：流量像正常散戶 → 最安全 最佳實踐：住宅 IP 作出口 + 中轉 VPS 做穩定連線。 整套架構 量化指令碼（本地 / VPS） ↓ mihomo 閘道器（分流規則） ↓ DMIT 香港 VPS（穩定中轉 + Xray 協議） ↓ IPRoyal 住宅 IP（最終出口） ↓ Binance API 為什麼不直接"本地 → IPRoyal → Binance"？ ...

Claude、ChatGPT、Perplexity 這類 AI 服務對出口 IP 質量非常敏感。如果你用普通 VPS（資料中心 IP）掛代理訪問，經常會遇到： 賬號登入觸發驗證碼 被要求重新驗證身份 某些功能被限制（Claude Projects、ChatGPT Plus 功能等） 請求被靜默降速 原因是這些服務的風控會識別 IP 來源，資料中心 IP 是已知的"代理流量"特徵，住宅 IP 則不是。 解決方案：AI 流量單獨走住宅代理，普通流量繼續走 VPS 節點。 架構概覽 本機 ├─ AI 服務請求（api.anthropic.com / api.openai.com / ...） │ └─ Surge → 住宅代理（SOCKS5/HTTP，家寬出口） └─ 其他流量 └─ Surge → VPS 節點（REALITY / Hysteria2） 住宅代理可以是： 家裡的軟路由 + 公網 IP（最優，完全真實住宅 IP） 商業住宅代理服務（IPRoyal、BrightData 等，按量計費） 本文以第一種（軟路由轉發）為例，第二種邏輯完全相同，只是替換代理地址。 ...

上一篇講了 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 計費，用多少買多少，不需要月付，質量穩定。 ...

家庭網路多閘道器架構那篇文章講了整體架構，但規則怎麼寫沒有細說。這篇單獨講 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 所屬國家分流： ...

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。 生成自簽證書 不需要域名的情況下，用自簽證書： ...

折騰了大半年的家庭網路，最終跑通了一套多閘道器冗餘架構。這篇文章分享整體設計思路，適合有一定折騰經驗、想把網路做得更穩定的朋友。 為什麼需要多閘道器 單閘道器最大的問題是單點故障：VPS 被封、線路抖動、機器宕機，整個網路就斷了。 多閘道器的核心價值： 線路冗餘：美國 / 香港 / 日本多個出口，自動選最快的 流量分離：不同流量走不同出口，既省流量又保速度 故障自動切換：某條線路掛了，其他線路自動頂上，使用者無感知 整體架構 家庭裝置 ↓ OpenWrt 主路由（DNS 分流 → dnsmasq） ↓ mihomo 閘道器（分流規則 → 策略組） ↓ 多個 VPS 出口（US / HK / JP） ↓ 目標網站 關鍵元件： 主路由：OpenWrt，負責 DNS 劫持和流量匯入 mihomo mihomo 節點：執行在獨立機器上，處理代理和分流邏輯 VPS 出口：推薦 DMIT，香港 / 美國節點延遲穩定，支援 Xray + Hysteria2 mihomo 分流規則設計 策略組分層 proxy-groups: # 手動選擇組（緊急備用） - name: "手動選擇" type: select # 自動選速最快節點 - name: "自動選擇" type: url-test url: "http://www.gstatic.com/generate_204" interval: 300 # 各地區組 - name: "🇺🇸 美國" type: url-test filter: "美國|US" - name: "🇭🇰 香港" type: url-test filter: "香港|HK" # 分流決策組 - name: "國內直連" type: select proxies: [DIRECT] - name: "AI 服務" type: select proxies: ["🇺🇸 美國", "自動選擇"] 規則優先順序 mihomo 規則從上到下匹配，順序很重要： ...