PassWall2 iStoreOS 安装配置：先查 opkg/apk，再按架构选包

更新于 2026-10-30 · passwall.lol

简答：在 iStoreOS 上安装 PassWall2，先执行固件、包管理器和架构核验命令，不要按设备名称直接猜安装包。输出为 opkg 时核对 ipk，输出为 apk 时核对 apk；x86_64、aarch64_generic、aarch64_cortex-a53 只用于筛选核心资产，LuCI 主包仍要以当前 Release 的完整文件名为准。安装后先用一个节点验证基础连通，再配置分流和 DNS。

定义：PassWall2 是运行在 OpenWrt 类系统 LuCI 界面中的网络代理管理插件，能否在 iStoreOS 上安装取决于固件分支、实际包管理器、DISTRIB_ARCH、软件源、依赖和存储空间是否匹配。

先做这一步：用设备输出决定 ipk、apk 和架构

本文是第三方使用指南，不代表 iStoreOS 或 PassWall2 项目官方。本文解决 iStoreOS 上 PassWall2 的安装、最小配置和基础验证；复杂 TUN、旁路由多网段、节点质量和完整 DNS 设计不在本文主流程内。

通过 SSH 登录设备，先保存以下输出：

cat /etc/openwrt_release
opkg --version 2>/dev/null || true
apk --version 2>/dev/null || true
grep -E 'DISTRIB_(RELEASE|REVISION|ARCH)' /etc/openwrt_release
cat /etc/opkg/distfeeds.conf 2>/dev/null || true
cat /etc/apk/repositories 2>/dev/null || true
df -h

iStoreOS 安装 PassWall2 的首轮决策表

设备输出	先核对什么	安装路径	停止条件
实际包数据库为 opkg	Release 中的 `.ipk`、当前 OpenWrt 分支、依赖仓库	LuCI 上传或 `opkg install`	仓库分支、签名或依赖不匹配
实际包数据库为 apk	Release 中的 `.apk`、APK 仓库、签名密钥	签名仓库安装或本地 apk	无法确认签名、仓库或固件分支
opkg 与 apk 命令同时存在	包数据库、软件源、已安装记录和 LuCI 软件页面	暂不安装，先确认系统实际使用的数据库	只凭 `command -v` 判断
无法读出固件分支或架构	`/etc/openwrt_release` 与设备固件说明	先补齐信息	不要用相近设备或相近分支的包强装

OpenWrt 官方包管理说明显示，OpenWrt 25.12 及更新版本使用 apk，24.10 及更早版本使用 opkg；但这是 OpenWrt 上游规律，不代表所有定制版 iStoreOS 都自动同步。iStoreOS 的更新说明也记录了 25.12 从 opkg 切换到 apk，并提示大版本升级前要备份，因此最终以设备实际包数据库为准。

架构速查：x86_64、aarch64_generic 和 aarch64_cortex-a53 怎么用

架构值的作用是筛选核心依赖和软件源路径，不是让你直接修改 LuCI 主包文件名。当前项目 Release 页面中的 PassWall2 LuCI 主包示例使用 _all 标识，但 xray-core、sing-box、tcping、geoview 等依赖可能按目标架构分别提供，必须逐项查看当前资产或仓库索引。

常见 DISTRIB_ARCH 输出与资产核对方法

设备输出	常见使用场景	应选择的资产	不能混用
`x86_64`	常见 x86 软路由、虚拟机或工控设备	选择资产名明确包含 x86_64 的核心包；LuCI 主包按当前包格式选择	不能改用 aarch64 或 armv7 核心
`aarch64_generic`	部分 64 位 ARM 通用目标	选择资产名明确匹配 aarch64_generic 或仓库索引明确支持该值的核心	不能仅因设备是 ARM 就使用 aarch64_cortex-a53
`aarch64_cortex-a53`	部分采用 Cortex-A53 的 ARM 设备	选择资产名或仓库架构明确匹配 aarch64_cortex-a53 的核心	不能仅凭“都是 ARM64”替换成 generic 包
其他值	厂商定制目标或其他 OpenWrt 目标	只使用当前 Release、仓库或固件说明明确支持的资产	不要从设备型号反推包名

实际操作顺序是：先读取 DISTRIB_ARCH，再打开项目 PassWall2 Release 页面，搜索该架构值或对应核心资产；如果只有 LuCI 主包而没有匹配核心，不要把 LuCI 菜单出现误认为完整可用。找不到对应资产时，停止安装并改查当前固件的软件源。

安装前准备：备份、软件源和冲突检查

备份配置：在 iStoreOS 的系统备份功能中保存配置，并把备份复制到电脑或其他存储位置。不要把唯一备份留在设备上。
记录恢复信息：记下管理地址、SSH 登录方式、默认网关、DNS、当前防火墙设置和已启用的代理插件。
检查空间：执行 df -h，确认 overlay 和 /tmp 有足够空间。空间不足时先清理日志和临时文件。
检查基础网络：确认设备能解析域名并访问当前软件源。下载失败不一定是包不兼容，也可能是默认路由或 DNS 本身异常。
检查代理冲突：记录 OpenClash、SSR-Plus 或其他会接管 DNS、防火墙和透明代理的组件状态。不要在没有备份时同时启用多个流量接管组件。
核对仓库：opkg 系统检查 /etc/opkg/distfeeds.conf；apk 系统检查 /etc/apk/repositories 和密钥目录。仓库分支与固件不一致时停止安装。

iStoreOS 的公开更新说明特别提醒，24.10 与 25.12 的包管理器不同，跨大版本保留软件包可能带来兼容问题。因此如果你正在升级固件，先完成备份，再单独核对 PassWall2 是否需要重新安装。

从项目 Release 选择包：版本、文件名和校验值都以当前页面为准

截至 2026-10-30，项目 Release 页面显示 26.10.29-1 为最新条目，并列出以下两个主程序资产：

luci-app-passwall2-26.10.29-r1.apk，SHA-256：9cc86f4af04ff54040039887e70685938e6c265522aaccb8cffb51eadb6d8b97
luci-app-passwall2_26.10.29-r1_all.ipk，SHA-256：a3b98e6218861e2ac4bb1dcd09b47426dc6bf82da4092715012cc067cefebcc6

这些版本、文件名和校验值会变化，只代表本次核验结果，不应写入长期自动化脚本。安装时以当前 Release 条目及其资产列表为准。页面上的发布标识与资产文件名可能分别出现 26.10.29-1 和 26.10.29-r1，不要自行推导固定命名规则。

确认当前系统实际使用 opkg 还是 apk。
确认 Release 中存在对应包格式。
确认核心依赖存在与你的 DISTRIB_ARCH 匹配的资产。
下载后执行 sha256sum 文件名，与当前 Release 显示值逐字比对。
任何一项无法确认，都先停止安装。

三种安装路径：软件源优先，本地包次之

路径一：当前签名软件源确实有 PassWall2

只有设备查询结果明确显示包存在时，才执行在线安装。opkg 系统可先执行 opkg update，再用 opkg list | grep -i passwall 查询；apk 系统可执行 apk update，再用 apk search -v '*passwall*' 查询。查不到时，不要直接执行固定的 apk add luci-app-passwall2，因为当前仓库可能没有该包或包名不同。

路径二：LuCI 上传已核验的本地包

在 LuCI 的软件管理页面更新列表，确认包格式后上传对应文件。安装完成后重新登录 LuCI，检查 PassWall2 菜单、已安装包记录和服务日志。菜单出现只能证明界面文件存在，不能证明核心依赖已经安装。

路径三：SSH 安装本地包

确认系统使用 opkg 且依赖可获取时，可使用：

opkg install /tmp/luci-app-passwall2_当前版本_all.ipk
确认系统使用 apk 且包签名可信时，可使用 apk add /tmp/当前版本.apk

PassWall2 项目文档说明，apk 本地安装使用 --allow-untrusted 会绕过签名验证；除非你已核对来源、校验值、依赖和回滚方案，否则不要把绕过签名当作默认修复方法。优先使用签名仓库或可核验的 Release 资产。

订阅、最小分流和 DNS：先建立可验证闭环

先导入一个明确协议的订阅或节点：使用你有权使用的配置，确认链接可访问、返回内容确实是订阅格式，并检查系统时间。
选择匹配核心：根据节点协议选择能解析它的核心。项目 Release 页面列出了核心版本，但不同核心支持的协议和字段并不完全相同，不能因为节点能导入就认为核心一定能启动。
先建立两个策略：创建“直连”和“代理”两个策略，代理策略只绑定一个已确认的节点；暂时不要同时开启 TUN、FakeDNS、IPv6 接管和复杂规则。
设置最小分流：在 PassWall2 的规则或访问控制页面中，先建立三层顺序：明确直连范围、明确代理范围、默认策略。若页面提供规则列表，确保更具体的域名规则排在通配规则前。
检查规则命中：访问一个应直连的域名和一个应代理的域名，分别查看 PassWall2 运行日志或规则命中记录；若只有 DNS 解析结果，没有 TCP、TLS 或规则日志，不要把它当成完整验证。
逐项处理 DNS：先确认路由器自身解析，再确认局域网客户端的 DNS 和默认网关是否指向 iStoreOS。DNS 能解析不代表代理链路、TLS 或分流全部正常。

最小配置的验证清单

检查层	动作	通过标准
插件层	查看 LuCI 菜单和服务日志	插件存在，日志没有持续启动错误
节点层	只启用一个明确协议节点	核心启动，节点状态不再反复失败
路由器层	从路由器测试 DNS 和 HTTPS	解析、TCP、TLS 分层结果一致
客户端层	确认默认网关、DNS 和规则命中	客户端流量出现在相关日志中
分流层	分别访问直连和代理范围	命中策略与预期一致

常见错误、停止条件和回滚

现象	优先检查	处理方式
Unknown package	仓库是否包含包、包名是否变化、列表是否更新	查询当前仓库，不要跨分支硬装
architecture incompatible	`DISTRIB_ARCH` 与核心资产是否一致	重新回到 Release 资产列表选择匹配项
签名或哈希错误	下载来源和校验值	停止安装，重新下载并核验
依赖缺失	依赖是否存在于当前软件源，是否属于另一分支	保留完整错误日志，不要混装不同分支包
订阅成功但没有节点	返回内容、格式、过滤条件、系统时间	先修复订阅输入，不要先调 MTU 或 TUN
路由器能用、客户端不能用	客户端默认网关、DNS、规则命中和 IPv6	先停用最近新增设置，再逐项恢复

回滚前先查询准确的已安装包名：

opkg list-installed | grep -i passwall
apk list -I | grep -i passwall

优先使用对应包管理器卸载刚安装的包，不要直接删除未知配置目录。若网络、DNS 或防火墙已经被修改，先停用新增策略，恢复安装前备份，再逐项验证。无法确认包数据库、软件源或架构时，最安全的做法是停止安装，而不是强制忽略依赖或签名。

补充说明：什么时候不适合继续安装

只知道设备型号，不知道 DISTRIB_ARCH。
opkg 与 apk 同时存在，但无法确认实际包数据库。
当前软件源属于其他固件分支，或签名验证失败。
Release 中没有与你的包格式或核心架构匹配的资产。
设备空间不足，且没有可恢复的配置备份。
已有其他组件接管 DNS、防火墙或透明代理，但你无法确认冲突范围。

出现以上任一情况时，先补齐核验信息或恢复基础网络，再继续操作。版本、资产和校验值会变化，页面引用的日期为 2026-10-30，以当前项目 Release 和设备实际输出为准。

常见问题

iStoreOS 安装 PassWall2 应该用 ipk 还是 apk？

先看设备实际使用的包管理器。使用 opkg 时核对 ipk，使用 apk 时核对 apk。OpenWrt 上游从 25.12 开始使用 apk，但 iStoreOS 是定制系统，仍应以设备实际输出、软件源和包数据库为准。

x86_64、aarch64_generic 和 aarch64_cortex-a53 可以混用吗？

不能仅凭名称相近或都属于 64 位架构就混用。先读取 DISTRIB_ARCH，再查看项目 Release 或仓库索引中明确匹配的核心资产。LuCI 主包的文件名和核心依赖的架构规则也可能不同。

可以直接执行 apk add luci-app-passwall2 吗？

只有当前签名软件源的查询结果明确包含该包，并且固件分支、包格式和依赖都匹配时才可以考虑。查询不到时，不要假设默认软件源一定提供 PassWall2，应改查当前 Release 或匹配的签名仓库。

PassWall2 安装完成但订阅里没有节点怎么办？

先检查订阅链接是否可达、返回内容是否为订阅格式、系统时间是否正确，以及页面过滤条件是否隐藏节点。再查看导入日志和核心日志，不要一开始就修改 MTU、TUN 或 IPv6。

路由器可以连接，但局域网设备不能连接怎么办？

先确认客户端默认网关和 DNS 是否经过 iStoreOS，再检查 PassWall2 日志中是否出现该客户端流量。若刚修改了 DNS 重定向、TUN、IPv6 或防火墙，先停用最近新增的设置并恢复原配置。

Release 页面中的 26.10.29-1 和文件名里的 26.10.29-r1 是什么关系？

这是本次 Release 页面同时显示的发布标识和资产文件名标识。不要根据这一组名称推导固定规则，下载时以当前资产列表中的完整文件名、包格式和校验值为准。