防火墙类型从当前插件的明确条件开始
OpenClash 分列 iptables 与 nftables、Firewall4 的依赖，Makefile 按是否装有 firewall4 选择模块。PassWall 与 PassWall 2 也有两个透明代理方向，不能把名称相同当成依赖全部一样。
| 当前工具 | 公开的防火墙核对内容 |
|---|---|
| OpenClash | 两套依赖和模块选择条件 |
| PassWall系列 | 按firewall4安装状态选择默认方向 |
| HomeProxy | 硬依赖firewall4及nft相关模块 |
| Nikki | README直接要求firewall4 |
OpenWrt 本次默认防火墙没有取得官方说明，不从系统版本替设备填一个默认值。当前已装组件、插件要求与实际规则分开，不把其中一项当成其他项已满足。
安装依赖与放行端口不是同一个动作
依赖模块提供插件运行所需的能力，不是某个服务器端口已经开放的证明。项目没有给端口被拦的通用判据，具体哪项阻断没查到公开说明，现象先保留。
- 记录固件、插件与防火墙方向，不只写网络不通。
- 对照明确依赖，缺项与运行错误分开描述。
- 不把相近模块名拼成一套未公开的规则或安装命令。
插件依赖回答需要什么组件，当前请求是否被阻断仍是另一项事实。
Nikki 的流程先混入并更新配置、运行内核，再设置相关路由和 nftables 规则，步骤随配置变化。这不是所有工具共用的规则顺序，也不是给任意设备手写放行规则的依据。
代理不通时按服务配置与输出逐层记录
- 看实际选择的插件和内核，确认问题发生在哪个对象。
- 保留配置取得及读入的提示，不从空列表先定端口原因。
- 服务起不来时查该插件公开的日志方式，再保存原文。
PassWall 2 有主日志与服务端日志两个路径，调试可在 Other Settings 启用。它们对应不同输出，不能用一类日志缺失推定另一类服务已经停止。
OpenClash 首次运行需要下载内核，Nikki 也有具体系统与核心条件。程序准备不完整和防火墙阻断是不同描述，不把安装流程里的所有失败统称为端口被拦。
插件冲突和系统调整没有依据时不补因果
这些项目没有说明彼此能否同时安装或运行，不能从同机出现多款就直接认定冲突，也不能自拟必须卸载某款的顺序。已有现象和实际说明并列，不写成已确认原因。
证书问题也另看相应核心公告，例如 PassWall 的 Xray 自签证书参数要求。它属于认证与校验条件，不由节点不能连接就统一改写成防火墙需要放行。
- 收集当前报错与动作，避免只留一项状态颜色。
- 对照插件自己的依赖、核心和证书条件。
- 没有明确放行说明时保留问题，不填随机端口或关闭校验。
服务来源准备更换时可继续看
若还需其他机场资料，下方入口可查看各自收录信息。
解惑答疑（常见问题）
代理不通就能先认定某个端口被拦吗？
资料没有给通用阻断判据，先区分配置取得、核心运行和服务输出。依赖、证书或其他提示也有各自条件，不能把网络现象直接改成端口原因。
依赖列表能直接当成放行规则抄吗？
依赖描述组件要求，不是具体流量规则。按当前插件对照所需模块，实际端口与阻断条件没有说明时不补一组命令，也不从模块安装证明请求已放行。
同机装了多个插件就必须先卸载另一款吗？
项目没有给统一并行规则，不能自行规定卸载顺序或认定冲突。保留已装对象、当前配置和实际报错，问题按对应插件公开说明逐项核对。