从 iStoreOS 到美国出口：我的斐讯 N1 旁路由实战与踩坑记录

我这次做的家庭网络改造，是把斐讯 N1 变成一台旁路由：安装 iStoreOS，用 OpenClash 做分流，再接入美国节点，让需要的手机和电脑通过它上网。

整个过程里，刷好系统只是起点。真正花时间的，是安装包版本、网关与 DNS、主路由的 IPv6，以及新节点和旧防火墙之间的配合。

最典型的现象是：YouTube 和 X 已经能用，ChatGPT 却仍提示所在地区不受支持。 后来发现，手机的一部分请求经过了 N1，另一部分却通过主路由的国内 IPv6 出口直连。

这篇文章按照实际配置与排查记录整理，希望把“怎么做”和“为什么这样做”一起讲清楚。

环境与时间：斐讯 N1、macOS、iPhone、iStoreOS 25.12.5；记录截至 2026 年 10 月 6 日。本文的系统是 iStoreOS，基于 OpenWrt。服务器地址、账号和节点凭据采用占位符，不能直接照抄。

记录范围：固件与烧录方案、旁路由配置、OpenClash、美国节点部署与故障修复都有历史记录。N1 首次启用 U 盘启动，以及是否实际写入内置 eMMC，没有完整操作记录；下文把这部分标为“安装前提 / 补充步骤”，依据项目说明与源码补齐。

一、先看懂这套网络，再开始配置#

这次没有让 N1 接管宽带拨号，而是采用单网口旁路由：N1 的网口接到主路由的 LAN 口，两者处在同一个局域网。手机仍然连接原来的 Wi-Fi。

各设备的分工如下：

“国内直连”的意思，是经过 N1 处理后，连接目标网站时使用本地宽带出口；“海外走代理”的意思，是 N1 把连接交给美国节点，再由节点连接目标网站。

N1 的上游网关是主路由；需要使用 N1 的手机，其网关是 N1。 这两个方向一定要分清。

这个结构也决定了旁路由的边界：它只能处理实际经过它的流量。设备使用其他网关、其他 DNS，或者获得了主路由下发的 IPv6 默认路由，都可能产生另一条路径。

二、给 N1 安装 iStoreOS#

1. 准备材料，选择 N1 专用镜像#

我的准备环境是 Mac 和一支 U 盘。还需要 N1、电源、网线；如果第一次启动后找不到设备地址，可以准备 HDMI 显示器与 USB 键盘用于排查。

固件从 iStoreOS 的 N1 下载目录 获取，确认文件名明确对应 N1。写作时目录中可见的 25.12.5 镜像包括：

istoreos-25.12.5-2026092410-n1-squashfs.img.gz

这是读者选包时的可核对示例；历史记录确认我的系统为 25.12.5，没有据此认定当时烧录的具体构建日期。

2. 在 macOS 上制作启动 U 盘#

macOS 这一步可以使用当时推荐的 balenaEtcher。从 Etcher 官方入口 下载适合自己 Mac 的版本，打开后按三个步骤写入：

1. Flash from file：选择 N1 镜像。
2. Select target：选择 U 盘，核对名称与容量。
3. Flash!：按提示授权，等待写入与校验完成。

Etcher 支持 GZ 镜像，可以直接选择 .img.gz。Etcher 格式说明

烧录会清空选中的 U 盘，先把里面的文件备份出来。烧录完成后，如果 macOS 弹出“无法读取此磁盘”，且 Etcher 已经校验成功，先安全推出即可。macOS 无法识别镜像里的 Linux 文件系统，并不等于 U 盘损坏；此时点“初始化”会破坏刚写好的启动盘。balena 对此现象的解释

3. 安装前提：N1 要具备从 U 盘启动的条件#

把镜像写进 U 盘，与让 N1 从 U 盘启动，是两个步骤。

如果 N1 原来已经运行 Linux / OpenWrt，并且具备 USB 启动能力，可在断电后插入启动盘、接好网线，再上电检查。如果仍是原厂安卓，则需要先按当前固件与引导状态完成对应的启动准备，可能涉及降级和 ADB 引导。

这部分没有保留下我的完整记录，因此不能把某一条 ADB 命令写成适用于所有 N1 的固定步骤。原厂安卓机器应先完成启动准备，再继续本教程；iStoreOS 项目关于 N1 的说明也指出，刷机路径与其他 Linux 固件一致，并说明了部分 eMMC 异常情况下恢复原厂固件的处理方向。项目维护者的 N1 说明

成功进入 iStoreOS 后，先在主路由的 DHCP 客户端列表查找 N1 的地址。N1 专用固件的初始网络行为与常见多网口软路由不同，项目说明其默认作为 DHCP 客户端获取地址，不要直接假定它的初始管理地址就是 192.168.1.250；250 是后面设置的固定地址。同一项目说明

找不到地址时，可连接显示器与键盘，在 N1 本机终端检查：

ip addr show dev eth0

找到实际地址后，用浏览器访问后台，按首次登录页面设置或修改管理密码。

4. 补充步骤：需要时写入内置 eMMC#

U 盘启动可以先用于验证系统。如果计划改为从 N1 内置存储运行，建议在安装插件和配置业务之前完成写入。

在 N1 的 iStoreOS 终端，先确认固件提供安装脚本：

command -v install-to-emmc.sh

确认当前从 U 盘启动、已备份内置存储的重要内容后，再运行：

install-to-emmc.sh

核对脚本列出的目标设备，根据提示确认写入，等它报告完成后执行 poweroff。关机后断电、拔掉 U 盘，再上电，检查是否能从内置存储进入系统。脚本未成功结束时，不要直接拔盘断电。

这一操作会重新分区并覆盖目标 eMMC。25.12 分支脚本复制启动与根文件系统分区，并将 overlay 标记为重置；不能把它理解为“把 U 盘中后来安装的插件和配置原样搬过去”。安装后需要重新确认 IP 与后台配置。iStoreOS 安装脚本源码

这段是为教程补齐的安装说明，并未把 eMMC 写入列为本次已确认完成的操作。

三、把 N1 设置为旁路由：我先在网关上踩了坑#

进入 iStoreOS 后，通过“网络向导 → 旁路由”配置。本次主路由地址是 192.168.1.1，N1 设置如下：

将 N1 固定地址排除在主路由动态地址池之外，或者按主路由能力做固定租约，避免其他设备获得同一地址。家里如果是 192.168.31.x 等其他网段，请按实际网段替换整套地址。

这次实际填错过的是：N1 的网关和 DNS 都变成了 Mac 的地址 192.168.1.65。

结果是电脑能打开 N1 后台，但 N1 自己无法正常出网；首页显示未联网，安装软件时也不断报下载错误。局域网管理页面能打开，只能证明“电脑能到 N1”，不能证明“N1 能到互联网”。

改成正确上游网关与可用 DNS 后，我才继续安装插件。

需要在终端核对时，可以先用这些只读命令：

# 在 N1 的终端执行
ip -4 route
nslookup downloads.openwrt.org

重点检查是否存在经主路由出网的默认路由，以及域名是否能解析。解析成功也只是其中一项，还需要实际下载验证。

四、安装 OpenClash：同样的错误提示，背后有两个原因#

这次主要使用 OpenClash。PassWall 是当时一起下载和检查过的另一套插件，不需要为了完成这条主流程同时启用两个透明代理服务。

坑 1：旧安装脚本调用 opkg，新系统已经换成 apk#

我最早拿到的包包括：

OpenClash_0.47.156+aarch64_core.run
PassWall_26.9.16_aarch64_a53_all_sdk_22.03.7.run

上传后，页面显示安装 / 软件源更新错误。真正有用的那一行是：

./install.sh: line 4: opkg: not found

排查确认，系统是 iStoreOS 25.12.5，包管理器已从 opkg 切换成 apk，而这些旧 .run 脚本还在调用 opkg 安装 .ipk 包。iStoreOS 25.12.5 更新说明

处理方法是下载适配系统大版本和架构的包。当时换用的 OpenClash 包为：

OpenClash_0.47.156+aarch64_core_sdk_25.12.run

可以从 25.12 软件包维护者发布页 查找。这个来源是第三方插件整合包维护者；发布页会更新，选包时核对 sdk_25.12 和架构。N1 系统的架构标识为 aarch64_cortex-a53，部分整合包文件名简写为 aarch64_a53，而该 OpenClash 整合包标记为 aarch64。

在 N1 上也可以查看：

cat /etc/os-release
uname -m

下载后进入“iStore → 手动安装”，上传对应 .run 文件，等待安装完成，再检查 OpenClash 菜单、核心和运行日志。

坑 2：换对安装包以后，N1 还是没法下载依赖#

第二次错误变成：

wget exited with error 4

这次需要查网络。我们先核对了软件源地址，再检查 N1 的已保存网络配置，定位到前面提到的网关 / DNS 误填。

旧包不兼容和网络配置错误，是先后出现的两个问题。 换包解决前一个，修正网关与 DNS 解决后一个；只反复上传安装包，不会让 N1 自动恢复出网。

我的经验是：先看日志中的第一条具体错误，再判断查版本、架构、网络还是依赖。不要只依据页面最后一句“更新错误”下结论。

五、先用已有美国节点跑通分流#

OpenClash 装好后，先导入原来的订阅 / Clash 配置，进入规则模式，配置透明代理与 DNS，再验证手机。

我的操作顺序是：

1. 保存当前可用配置的备份。
2. 在“配置订阅”录入自己的订阅，或在“配置管理”上传 Clash YAML。
3. 查看节点是否出现，选择一个可连接的美国节点。
4. 检查策略组与规则，确保 AI、流媒体与社交连接落到预期组。
5. 在插件设置中检查透明代理 / TUN 和 DNS 接管是否已启用，重启后查看启动日志。
6. 让一台测试手机的网关与 DNS 指向 N1，再从手机发起实际请求。

本次最终运行中，OpenClash 的 TUN 已启用；不要只凭 YAML 上传成功或节点列表有延迟，就认为客户端已被接管。

1. 我的分流目标#

海外组不放 DIRECT 作为自动回退选项，空组回退设为 REJECT。不过，这个设置只约束内核运行时的策略选择；要在 OpenClash 整体停止时也阻止国外直出，需要独立防火墙配合。

本次还拦截了 UDP 443、常见 STUN 的 UDP 3478 / 5349 和外发 DoT 853。因此“海外默认走代理”存在这些阻断例外，不能说所有协议都无条件可用。相关端口策略可能影响语音会议、Discord 或游戏，应按自己的用途评估。

2. DNS 也要一起分流#

这套配置使用 Fake-IP：国内域名优先使用国内 DoH，海外域名通过美国策略组使用 Cloudflare / Google DoH，并让 DNS 遵循策略规则。Fake-IP 地址是代理内部的映射结果，不能拿它当真实网站服务器地址判断地区。Mihomo DNS 配置说明

我当时还找过 AdGuard Home、mosdns 的安装包，但没有把它们作为这次已经验证完成的网络链路。想增加去广告或自定义解析，建议在现有链路稳定后再做。

3. 手机的“路由器”和 DNS 都要改#

在 iPhone 的“设置 → Wi-Fi → 当前网络旁的 ⓘ”里：

• 配置 IP → 手动：填写同网段内属于这台手机的独立 IPv4 地址、子网掩码，路由器填 192.168.1.250。
• 配置 DNS → 手动：仅保留 192.168.1.250。

手动 IPv4 地址要避免与其他设备和动态地址池冲突，也可以先在主路由做相应的固定租约安排。不要把手机 IP 填成 N1 的 250。

家里有 2.4 GHz 和 5 GHz 两个 Wi-Fi 名称时，分别检查。系统往往按网络保存设置，改好一个网络，不代表另一个也已改好。

六、最费时间的坑：手机通过 IPv6 绕过了 N1#

当时手机连接 Wi-Fi 后，YouTube 和 X 已经可以使用，但 ChatGPT App 的邮箱登录失败，Safari 网页也提示地区不可用。

我最先怀疑登录认证域名漏了分流，例如只覆盖了 chatgpt.com，却没有覆盖认证服务。

检查日志后，发现 auth.openai.com、ios.chat.openai.com 等连接已经命中了美国 AI 组；切换另一个美国节点后，问题仍然存在。已有的 DOMAIN-SUFFIX,openai.com 规则也覆盖认证子域名，因此继续重复添加同一域名，缺少依据。

1. 关键证据来自手机真实出口和主路由广播#

后来在手机上检查认证域名出口，看到国内 240e:… IPv6 和 loc=CN。在飞行模式下单独开启 Wi-Fi再测试，仍是同样的国内出口，排除了这次请求由蜂窝网络回退造成的情况。

N1 上的抓包又捕获到主路由发布 IPv6 RA，广播的前缀与手机错误页一致，并提供 IPv6 默认路由与 DNS。邻居表核对确认广播来自主路由。

这条证据链解释了看似矛盾的现象：

部分 IPv4 请求：手机 → N1 → 美国节点
部分 IPv6 请求：手机 → 主路由 → 国内运营商

手机手动设置的 IPv4 网关，不会覆盖 IPv6 默认路由。 IPv6 可以通过路由器通告独立发现网关；只关闭 N1 的 IPv6，也无法拦住没有经过 N1 的请求。IPv6 邻居发现与路由器通告规范

2. 这次的修复：关闭主路由 LAN 侧 IPv6 广播#

普通管理账号没有 IPv6 控制项。后来通过已有的高级管理权限进入主路由，实际路径是：

网络 → 用户侧管理 → IPv6 设置。

本次取消了以下勾选并保存：

“地址信息是否通过 DHCP 获取”和“slaac 前缀使能”原本就没有勾选。保存后重新进入页面，确认关闭状态已保留。

这是本次使用的电信家庭网关界面。其他型号的菜单、端口和选项名称可能不同，应以自己的设备为准。

这里调整的是主路由面向该 LAN 的 IPv6 配置，WAN、宽带拨号、IPTV 与语音设置没有改动。代价是这个 LAN 上的设备无法继续依靠这些通告获得正常的 IPv6 接入；如果要保留 IPv6，就需要设计一条由旁路由正确接管的 IPv6 路径，或使用隔离的下游网络。

3. 关闭以后重新连 Wi-Fi，并补好 DNS#

保存后让手机在“设置”中关闭再开启 Wi-Fi，重新连接，检查 IPv4 网关和手动 DNS 都是 250。旧的 IPv6 路由状态不一定在保存页面后立刻消失，应以重新连接后的客户端测试为准。

这一步又出现了一个实际问题：之前能用的 YouTube 突然打不开。后来补上手机的手动 DNS，我确认它恢复了。

当时也试过为指定 Wi-Fi 生成关闭 IPv6 的 iPhone 描述文件，我安装过，后来又提出删除；它的实际禁用效果没有得到独立确认。因此本文采用后来完成的主路由修复路径。删除描述文件后，也要重新核对对应 Wi-Fi 的网关与 DNS。

后续手机认证域名的一次探测显示 loc=US，出口与海外节点地址范围一致，之前的国内 IPv6 路径没有在这次探测中出现。这说明该次连接的出口已正常，仍需要实际登录来确认业务结果。

4. 看到 IPv6 地址，不一定是泄漏#

原来的海外节点本身也可能用 IPv6 连接目标网站。此时检测页看到的 IPv6 属于美国节点，和手机从国内主路由直出的情况不同。

判断时要结合实际地址归属、该请求的地区信息和路径证据。不能只看地址里有冒号，就认定泄漏；fe80:: 链路本地地址本身也不能证明公网泄漏。

七、再搭一个独立美国节点，用同一套规则做对照#

修复网络路径之后，我又遇到 Muse 注册的地区提示。我们观察到的相关接口已走美国组，这时需要进一步区分出口识别、账户和 App 差异。

于是我接入另一台美国服务器，创建独立节点。供应商把它描述为“美国住宅 IP”，但这次独立验证完成的是美国出口和连接可用性，住宅属性没有独立核实。

1. 在服务器部署 Geto 面板#

本次服务器环境是 Ubuntu 22.04 LTS / x86_64，已经通过 Termius 建立 SSH 连接。按 Geto 的部署教程 操作，安装前检查系统、监听端口，并阅读安装脚本。

教程给出的安装命令是：

# 在自己的美国服务器 SSH 终端执行
bash <(curl -fsSL https://www.geto.im/panel/install.sh)

这是带系统权限的第三方安装脚本，执行前应核对下载内容和当前教程。安装结束后妥善保存面板登录信息；文章里不公开管理员密码或节点分享链接。

本次面板为 Geto v2.1.0，使用 np-panel.service，面板端口为 2053/TCP。在服务器上确认服务状态：

systemctl status np-panel --no-pager

2. 坑：Chrome 直接打开公网面板出现 403#

本次 Chrome 访问服务器公网 HTTP 面板时返回 403；同一 Mac 的直接探测确认服务器可以响应。现有记录没有把这次 403 的具体来源完全定位。

为继续操作，我在 Termius 建立了本地 SSH 转发：

启动转发后，在 Chrome 打开：

http://127.0.0.1:12053/

这里的 127.0.0.1 是本机地址，本地 12053 通过 SSH 转到服务器上的 2053。Termius 转发需要保持连接；关闭后入口也会失效。本地 SSH 转发也不能替代服务器公网面板本身的访问控制。

3. 创建并导出 VLESS 节点#

进入面板的“入站管理”，添加入站，选用本次测试的协议组合，并核对以下参数：

启用节点，确保服务器防火墙和供应商安全组允许对应 TCP 端口，再从面板导出 Clash Meta 配置。端口、SNI、UUID、Public Key、Short ID 都以自己的服务端导出结果为准。Geto 协议与导出说明

下面是节点片段示例，只用于展示字段，不是一份完整 OpenClash 配置：

proxies:
  - name: US-Residential-Test-01
    type: vless
    server: YOUR_SERVER_IP
    port: 57708
    uuid: YOUR_UUID
    network: tcp
    tls: true
    flow: xtls-rprx-vision
    servername: www.cloudflare.com
    client-fingerprint: chrome
    skip-cert-verify: false
    reality-opts:
      public-key: YOUR_REALITY_PUBLIC_KEY
      short-id: YOUR_SHORT_ID

对应字段可查阅 Mihomo VLESS 文档 和 TLS / Reality 配置文档。公开稿中的 YOUR_... 都要替换；Reality 私钥保留在服务器，客户端使用导出的公钥。

4. 先单独验证，再接进 N1#

我先在 Mac 用临时 Mihomo 客户端测试新节点，监听只绑定本机回环地址，关闭测试实例的 TUN 和 DNS。这样可以先验证节点本身，不用立刻改动整套家庭网络。

当时完成了配置校验、节点端口连接、实际代理 HTTPS 请求、证书校验，并在面板观察到流量；Cloudflare 探测显示 loc=US，ipify 返回的出口与服务器一致。

这证明节点连通和该次美国出口探测成功，没有证明目标 App 已经完成注册。

八、接入软路由时，又被旧防火墙拦住了#

为了方便对照，我保留了两份配置：

制作第二份配置时，以原来可用的分流配置为基础，替换节点，将策略组名称加上 住宅- 前缀，并同步修改规则、组间引用和 DNS 地址中的策略组后缀。

这次保留了 121 条规则对应的分流逻辑、DNS 分流和 IPv6 设置。独立组名让两套配置的选择状态不互相混用，也便于在相同规则下比较出口。

随文附有美国节点分流参考模板，保留这套规则和 DNS 策略，节点与代理认证信息全部替换为占位符。使用前需要填写自己的参数，并在 OpenClash 中另行配置 TUN、DNS 接管和所需的数据文件；模板没有包含独立 nft 防护、主路由设置或自动订阅脚本，不能直接导入后就视为完成防泄漏配置。

不要直接用面板导出的完整默认配置覆盖已有的家庭分流配置：先核对其中的 proxies、策略组、规则与 DNS，避免导入节点时一起改变整个网络策略。

1. Mac 能连，N1 上却连接超时#

上传后，N1 日志显示连接新节点超时：

dial tcp YOUR_SERVER_IP:57708: i/o timeout

这行已经替换了真实服务器地址。当时的根因是：我们之前配置了独立的出口防护，它只允许原有 15 个节点的准确 TCP 端点，读取脚本也只接受 Trojan 节点。

新节点使用 VLESS + TCP + Reality + Vision，服务端虽然正常，却没有被 N1 的允许列表放行。

2. 这次做了哪些修复#

处理的是自己部署的防护层：

1. 备份防护脚本、端点缓存与当前 nft 规则表。
2. 扩展参数读取，支持本次 VLESS TCP Reality Vision 节点。
3. 同时读取两份保留配置，将新节点的准确 IP 与 TCP 端口加入允许列表。
4. 做配置与 nft 内核规则检查，再应用规则。
5. 通过防护服务入口重载，验证切换配置后仍能运行。

相关路径是：

/etc/openclash/router-privacy-guard.sh
/etc/openclash/oc-privacy/endpoints.tsv
inet oc_privacy

它们是这次额外部署的脚本、缓存和 nft 表，属于本环境的自定义防护，并非每台 OpenClash 都默认存在。

本次放行后，节点端点从 15 个变成 16 个，原来的限制继续保留。修复后，通过 N1 的代理再次访问 Cloudflare 与 ipify，确认新出口可用；切回原配置也验证成功，原配置内容的校验值与修改前一致。

当独立客户端可用、路由器却超时时，要沿着这条路径查：配置参数 → 路由器 DNS / 路由 → 本地出口防护 → 服务端端口。 不要仅凭超时就认定美国服务器不可用。

3. 两份配置如何切换#

在 OpenClash 中：

1. 打开“配置管理”。
2. 点击目标 YAML 所在行的“切换”。
3. 进入“运行状态”，点击“重启”。
4. 等待启动成功，核对日志中的节点和策略组，再从手机测试。

截图中的“住宅”是本次测试配置的命名，不能当作 IP 属性认证。

这个版本页面最右侧的“应用”，用于执行“其他”下拉菜单里的节点管理等操作；实际切换配置使用的是单独的“切换”按钮。

九、如何验收：美国 IP 正常，不等于所有 App 都能注册#

我现在会按五层检查：系统出网、代理连通、客户端出口、DNS / 旁路路径、目标业务。

1. 先从手机验证真实出口#

先开飞行模式，再单独开 Wi-Fi，完全退出相关 App 后重新打开。这样便于排除本次测试的蜂窝回退和旧连接影响；日常恢复蜂窝网络后，还要补做一次实际使用验证。

可以访问 Cloudflare 的 trace 诊断入口，关注 ip、loc 和 colo；针对出问题的域名，也可在其提供该诊断入口时测试。OpenClash 连接记录用于核对这次请求实际使用的组和节点。Cloudflare 诊断入口说明

本次新节点的探测结果，隐去实际地址后为：

ip=本次新节点的出口地址
loc=US
colo=LAX
tls=TLSv1.3

loc=US 表示 Cloudflare 对该次请求出口的地区识别；colo=LAX 是服务接入点标识，不能单凭接入点就认定客户端的国家。它们不是所有平台共用的地区判断结果。

2. DNS 检测与真实出口分别看#

后续手机 DNS 检测截图显示 Cloudflare，没有看到国内运营商解析器，符合当时海外解析的预期。

DNS 检测里的“美国 / 洛杉矶”描述的是检测到的解析服务，不能据此证明手机所有业务连接都从美国出去；多条 DNS 结果也不必然代表异常。出口和登录结果仍要单独验证。

3. HTTP 403 不等于节点完全无法连接#

这次针对部分服务做的无登录命令行探测，已经完成 HTTPS 和证书验证，随后得到 403 或认证跳转。这能说明连接到达了服务，但不能替代浏览器 / App 的登录，也不能据此确定平台拒绝的具体风控原因。

同样，“供应商称住宅 IP”“检测站显示美国”“收到 +1 号码的验证码”，都不足以单独证明某个 App 的注册资格检查一定通过。

4. 本次实际确认到哪里#

十、给同样折腾 N1 的朋友留一张排错表#

更换节点或调整网络之前，保存 iStoreOS 设置、OpenClash YAML 和自定义防火墙的备份。排错时优先一次改一个变量，让测试结果能够对应到具体变化。

这次折腾让我最有用的收获，是学会沿着真实请求的路径查问题：设备交给了谁，DNS 在哪里解析，IPv4 与 IPv6 分别往哪里走，防火墙又允许了哪些端点。

把这些环节核对清楚，再讨论节点质量与应用限制，判断就有依据了。