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 规则从上到下匹配，顺序很重要： ...