家宽IP原来这么简单？不改服务器不换客户端，一段脚本搞定

最近一直看到不少朋友在研究分享家宽IP，看着手痒我也去搞了一个静态住宅IP，实际接了一遍。

接之前我以为会很麻烦，要改服务器、要换客户端。结果测下来，远没有想象中那么复杂：不动服务器，不换客户端，在Clash Verge里粘贴一段脚本就接好了，而且哪些流量走家宽、哪些不走，都可以自己控制。

先叠个甲：我也是第一次玩家宽IP，这篇记录的只是我自己跑通的一种做法，不一定是最好的。文章里有说得不对的地方，或者你有更好的玩法，欢迎在评论区补充，我也想多学一点。

接入的方式不止一种。这一篇先用最简单的客户端链式代理来做，只改电脑上的Clash。服务端链式代理的方案，我后面测试完会再单独分享。

家宽IP怎么用起来

家宽IP是什么

VPS的IP归属于云厂商和数据中心，也就是常说的机房IP。不少网站会区别对待这类IP：验证码变多、注册受限、账号更容易被风控。

家宽IP，也叫住宅IP，是由ISP（宽带运营商）分配的。在网站看来，它是一个普通的家庭宽带用户。

住宅IP又分动态和静态两种。动态的会不停更换，静态的长期固定不变。日常登录账号用的是静态住宅IP，本文说的也是这一种。

买到手的是什么

静态住宅IP买到手，后台给的通常是一组代理信息：主机、端口、账号、密码，协议是SOCKS5或HTTP。

问题在于，它不能从国内直接使用，原因有两个：

• 有些服务商明确说明不支持大陆直连。 需要在境外的网络环境下才能连接。

• 这两种协议本身不加密。 即使能连上，流量也是明文传输的，不稳定，也不安全。

所以它一般不单独使用，而是要和现有的节点配合。

常见的几种接法

下面是我目前了解到的几种，可能不全：

中间两种都叫链式代理，思路是一样的：过墙的那一段继续用原来的节点，出墙之后再把流量转交给住宅IP。

平时的链路：

电脑 → 原有节点（VPS）→ 目标网站

链式代理多了一跳：

电脑 → 原有节点（VPS）→ 住宅IP → 目标网站

原有节点负责翻墙和加密，也叫前置节点；住宅IP负责出口身份，也叫落地节点。网站看到的是后者。

我今天用的是客户端链式代理。它改动最小，不想用了把脚本清空就恢复原样，第一次上手用它比较合适。

本文以我自己的环境为例：

你的节点和住宅IP大概率和我不一样，做法是相同的。

我是怎么接的

准备工作

需要三样东西：

1. Clash Verge Rev，或者其他使用mihomo内核的客户端。

2. 一个已经能正常使用的订阅。 它里面的节点会作为前置节点。

3. 住宅IP的四项信息。 代理主机、端口号、账号、密码，在购买的后台里复制。

第一步：先确认住宅代理本身能用

这一步需要一台自己的VPS。如果你用的是机场订阅，没有VPS，可以跳过这一步，直接往下做。

登录你的VPS，执行下面这条命令，把四项信息换成自己的：

curl -x "socks5h://账号:密码@代理主机:端口" "https://ipinfo.io"

返回结果里的ip如果是后台显示的那个出口IP，就说明代理可用。

如果不通，把开头的socks5h换成http再试一次。HTTP能通的话，后面脚本里的协议类型也要相应改成http。

第二步：打开订阅的扩展脚本

打开Clash Verge，进入左侧的「订阅」页面。在你正在使用的那张订阅卡片上点右键，选择「扩展脚本」。

这里有两点要注意：

• 不要直接编辑订阅文件。 订阅每次更新都会重新下载，直接改的内容会被覆盖。扩展脚本是在订阅更新之后自动叠加上去的，不受影响。

• 不要用页面顶部的「全局扩展脚本」。 它会作用到你的所有订阅。

有些教程写的是右键菜单里的「编辑节点」。它也能用，但只管节点这一段，代理组和分流规则还要分别到「编辑代理组」和「编辑规则」里添加，一共要改三处。扩展脚本一处就能全部完成。

第三步：粘贴脚本

编辑器里原本有一个空的main函数。把里面的内容全部替换成下面这段：

// 链路：本机Clash -> 订阅原有节点（前置） -> 住宅IP（落地） -> 目标网站

// 住宅节点：四项信息来自购买的后台
const RESIDENTIAL = {
  name: "🏠 住宅IP-US", // 可以改名，但要保留「住宅IP」字样（下面按它做过滤）
  type: "socks5", // 不通时可以改成 "http"
  server: "你的代理主机",
  port: 5001,
  username: "你的账号",
  password: "你的密码",
};

const FRONT_GROUP = "🔗 住宅前置"; // 住宅节点经由谁连出去
const EXIT_GROUP = "🏠 住宅出口"; // 住宅IP的统一出口

// 默认就走住宅出口的网站。这里先放IP检测类网站，用来验证
const RESIDENTIAL_RULES = [
  "DOMAIN-SUFFIX,ipinfo.io",
  "DOMAIN-SUFFIX,ping0.cc",
  "DOMAIN-SUFFIX,ippure.com",
  "DOMAIN-SUFFIX,ipsuper.com",
  "DOMAIN-SUFFIX,net.coffee",
  "DOMAIN-SUFFIX,scamalytics.com",
  "DOMAIN-SUFFIX,browserleaks.com",
];

function main(config, profileName) {
  const proxies = config.proxies || [];
  const groups = config["proxy-groups"] || [];

  // 订阅原有的全部节点，作为前置。每次动态获取，节点改名也不受影响
  const frontNames = proxies.map((p) => p.name);
  if (frontNames.length === 0) return config;

  for (const g of groups) {
    // 会自动收录全部节点的分组：把住宅节点排除，避免被自动测速选中
    if (g["include-all"] || g["include-all-proxies"]) {
      g["exclude-filter"] = g["exclude-filter"]
        ? `${g["exclude-filter"]}|住宅IP`
        : "住宅IP";
    }
    // 给所有手动选择的分组追加「住宅出口」选项（广告拦截类分组除外）
    const isSelect = g.type === "select" && Array.isArray(g.proxies);
    if (isSelect && !g.proxies.includes("REJECT")) {
      g.proxies.push(EXIT_GROUP);
    }
  }

  // dialer-proxy：连接住宅节点之前，先经过前置组。这一行就是链式代理
  proxies.push({ ...RESIDENTIAL, "dialer-proxy": FRONT_GROUP });

  groups.push(
    { name: FRONT_GROUP, type: "select", proxies: frontNames },
    // 第二个选项用于故障回退：跳过住宅IP，直接从前置节点出去
    { name: EXIT_GROUP, type: "select", proxies: [RESIDENTIAL.name, FRONT_GROUP] },
  );

  config.proxies = proxies;
  config["proxy-groups"] = groups;
  // 新规则放在最前面，优先于订阅自带的规则
  config.rules = [
    ...RESIDENTIAL_RULES.map((r) => `${r},${EXIT_GROUP}`),
    ...(config.rules || []),
  ];
  return config;
}

需要改的只有最上面的四项：server、port、username、password，换成你自己后台里的值。其他内容不用动。

改好后点保存，Clash Verge会自动重新加载配置。

这段脚本一共做了四件事：

第四步：看一下代理页面

进入左侧的「代理」页面，应该能看到多出了两个分组：

同时，订阅里原有的每个分组，都多了一个「🏠 住宅出口」的选项。

这两个分组容易搞混，可以这样记：

• 「住宅前置」是住宅节点的上一跳，不是出口。 只有一个节点的话，它里面也只有一个选项，放着不用管。

• 「住宅出口」才是给你用的。 想让流量走住宅IP，选的都是它。

验证是否生效

在终端里执行下面两条命令。前提是Clash Verge开启了虚拟网卡模式（TUN）。只开了系统代理的话，终端里的curl默认不走代理，可以改用浏览器打开这两个网址来看。

curl "https://ipinfo.io"
curl "https://ifconfig.me/ip"

• 第一条显示的应该是住宅IP。ipinfo.io在脚本的规则里，默认走住宅出口。

• 第二条显示的应该是VPS的IP。它不在规则里，仍然走原来的节点。

两条结果都符合，就说明链式代理和分流同时生效了。

日常怎么用

1. 让某一类流量走住宅IP。 在「代理」页面里找到对应的分组，比如「AI服务」，点选「🏠 住宅出口」。

2. 让某个网站固定走住宅IP。 在脚本的RESIDENTIAL_RULES里加一行，然后保存：

"DOMAIN-SUFFIX,example.com",

3. 住宅IP出故障时一键回退。 在「🏠 住宅出口」分组里，切到「🔗 住宅前置」。所有选了住宅出口的分组会一起回退到前置节点，不需要逐个改回来。

4. 彻底撤销。 把扩展脚本改回下面这样并保存，一切恢复原样：

function main(config, profileName) {
  return config;
}

几个要注意的地方

下面是我今天折腾过程中记下来的，有些是踩到的坑，有些是我自己的理解，不一定都对。

延迟会变高，下载速度影响不大

流量多经过了一跳，我原本以为速度会掉不少。实际测下来要分两种情况看，下面的数据只代表我这一条线路。

先看延迟，测的是新建一次连接的耗时。同一个网址，两种出口交替各测6次：

走住宅IP之后，新建连接的耗时接近原来的两倍。 我又换了两个网址测，结果在1.6倍到2.2倍之间。

再看下载速度，同一个50MB的测速文件，两种出口交替各下载3次：

两边基本没有差别，单次的波动都比这个差距大。

所以我的实际感受是：打开网页的第一下会慢一点，开始传输之后差别不大。

视频、下载、系统更新这些大流量，我还是留在原来的节点上。倒不是因为慢，而是没有必要，有的住宅IP套餐还限流量。只让需要「干净身份」的那一部分流量走住宅IP就够了。

一个服务别拆成两个出口

如果主站走住宅IP，登录接口却走VPS，对方会看到同一个账号的IP来回跳，这可能比完全不用住宅IP还要糟。所以我更倾向于用订阅里已经按服务划分好的分组来切换，而不是零散地添加一两个域名。

前置节点选近一点的

我的前置节点在洛杉矶。在Clash里测了一下延迟，从它直接出去是135毫秒左右，经过住宅IP是275毫秒左右，一次往返多了约140毫秒。这里测的是连接建立之后一次往返的时间，和前面新建连接的耗时不是同一个指标。这说明前置节点和住宅IP离得并不近，应该也是我这边延迟偏高的原因之一。如果订阅里有多个节点，可以在「🔗 住宅前置」里选一个离住宅IP所在地更近的试试。

域名入口还是出口IP

有的后台会同时提供两种连接地址：一个是域名形式的入口，一个是出口IP本身。后者少经过一次中转。

我两种方式各测了5次，平均耗时分别是1.78秒和1.66秒，只差0.12秒，实际使用中感觉不出来。

所以两种方式都可以。我自己目前用的是出口IP方式；如果更看重省心，可以用域名方式，对方调整线路的时候，配置不用跟着改。

这个IP干不干净

接入只是第一步，IP的质量怎么样，还得自己查一下。下面是我自己常用的几个检测站点：

其中ip.net.coffee的分流测试我觉得很实用。它会列出访问不同网站时实际使用的出口IP，正好可以用来确认分流规则有没有按预期生效。

命令行里我用的是ipinfo.io，前面验证用的第一条命令就是它。另外还有scamalytics.com（欺诈风险分）和browserleaks.com（WebRTC和DNS泄漏）可以参考。

这些站点脚本里都默认走住宅出口，打开就能直接检测。有两点要留意：

• 不同站点的结果可能不一样。 它们背后用的IP数据库不同，定位、类型、风险分都可能有出入，多看几个再下结论。

• 站点显示的不是住宅IP时，不一定是配置错了。 有些检测站是通过其他域名的接口来识别IP的，只让站点本身走住宅出口不一定够。这时可以直接在站内输入住宅IP来查询。

想自己改脚本的话

这段脚本是我边试边改出来的，中间遇到过三个问题，改的时候可以留意一下：

• dialer-proxy不要写死节点名。 有些订阅的节点名里带着剩余流量，每次更新都会变。脚本让它指向一个代理组，组里的节点名每次动态获取。

• 住宅节点要从自动分组里排除。 订阅里设置了include-all的分组会把它也收进去，可能被自动测速选中。脚本用exclude-filter处理了这一点，所以节点名里要保留「住宅IP」字样。

• 分组之间不能互相引用。 「住宅出口」的备选项不能是「节点选择」这类主分组，否则会形成环路，Clash会拒绝加载配置。

写在最后

到这里，电脑上就多了一个家宽IP的出口。总结一下整个过程：

家宽IP听起来门槛很高，实际接下来，本质上还是在改配置文件。我觉得更需要花心思的反而是维护好一份适合自己的分流规则。

这篇用的客户端链式代理，只对这一台电脑生效。想让手机和其他设备也用上，需要在服务器上配置服务端链式代理，这个方案我接下来会去测试，跑通之后再单独写一篇分享。

感谢看到这里，如果这篇文章对你有帮助的话，欢迎关注、点赞、收藏。如果有其他想看的干货文章或者文章中存在错误的地方，也欢迎在评论指出。我们下篇文章再见。