常见问题

安装提示不兼容

运行菜单的检查环境，结合具体项目判断：CPU / ABI、内核功能、BTF、模块、空间和 LuCI 都需要符合要求。

• ARMv7 / MIPS 回调加载失败：属于已确认的内核限制，当前不推荐作为透明代理使用，不能靠换一个同名架构安装包解决。
• BTF 无效或不匹配：需要与当前内核对应的 BTF，不能下载任意 vmlinux 覆盖。
• 缺少内核模块：从当前固件软件源安装匹配 ABI 的依赖，不使用其他固件模块强装。
• 空间不足：同时检查临时目录和 overlay，包含解压与备份所需空间，不只看压缩包大小。

能检查更新，但下载失败

检查版本访问 api.github.com，安装文件通常还要经过 github.com 和 release-assets.githubusercontent.com。能显示新版本，不代表这些下载地址都能访问。 0.6.49 起增加有限重试、IPv4 回退和 GitHub 官方 API 文件入口，大安装包允许更长传输时间；不使用第三方镜像，也不关闭证书验证。

新版会区分解析失败、证书错误、连接超时、中断、访问限制和文件缺失。下载与校验在停止服务之前完成，失败保留原服务、节点和配置。 官方备用入口也可能跳转到同一下载服务器；若该服务器无法访问，仍需处理路由器自身的 DNS 或出口。

若提示固件软件源或依赖检查失败，应检查固件自己的软件源，不要改用其他固件的软件包。 若提示安装准备超时，原代理尚未停止；可稍后重试。手动升级后看到上次任务失败记录时，先核对当前版本，再点击“检查更新”。

0.6.38 等旧版本如何获得修复？

旧更新器不能在下载新脚本之前修复自己。若版本检查正常、下载一直失败，可在路由器 SSH 通过同仓库官方 API 获取新版脚本，执行保留配置的更新：

uclient-fetch -T 60 --header='Accept: application/vnd.github.raw+json' \
  -O /tmp/nailink-install.sh \
  'https://api.github.com/repos/slobys/NaiLink/contents/openwrt/install.sh?ref=openwrt-v0.6.79' \
  && sh /tmp/nailink-install.sh --install --update-only --release openwrt-v0.6.79

这不是卸载重装。脚本先准备并校验新包和旧版回退包，之后才停止服务与备份。若仍下载失败，不会停用原服务；不要删除节点或反复卸载。

先在路由器 SSH中检查：

nslookup github.com
nslookup raw.githubusercontent.com

电脑能访问网页，不代表路由器自身 DNS 和下载出口可用。旧版只有 Raw 入口失败时，可尝试固定版本更新：

nailink --install --release openwrt-v0.6.79

新版本菜单会在 Raw 下载失败后尝试同仓库的 GitHub 官方 API，并在可用时回退固件的下载工具；没有使用第三方镜像。如果 GitHub 也无法解析，仍需先处理 DNS 或网络。下载失败时不要删除节点或关闭 HTTPS 证书校验。

菜单没出现，或页面打不开

• 升级后重新登录后台并强制刷新。旧菜单名为 Daed，新版为 NaiLink。
• 从 LuCI 的“服务 → NaiLink”进入；内部 127.0.0.1:2023 不是提供给其他设备直接访问的地址。
• 确认使用具有管理权限的 LuCI 账户。只读权限不等于可以修改代理。
• 页面提示管理服务未启动时，使用页面提供的启动入口；仍失败再看运行日志。

root 登录后仍提示授权失败

先更新到 0.6.79，再重新加载路由器后台。新版优先读取 LuCI 当前 RPC 会话，兼容没有该接口的旧版；授权失败时会显示诊断代码，不必执行 SSH 命令。

• session_expired：会话已过期，请退出后台后重新登录。
• session_missing：没有取得有效会话，请重新加载；仍失败时可能是固件的 LuCI 会话接口不兼容。
• permission_denied：会话有效，但缺少插件管理权限。使用 root 重新登录；仍失败时，通过安装菜单更新插件，重新部署权限文件。
• origin_rejected：网页来源不匹配。使用路由器原始后台地址，核对反向代理的域名、端口与 HTTPS 配置。
• rpc_unavailable / rpc_timeout：授权服务不可用或超时，不代表密码错误。稍后重试；持续失败时检查固件的 ubus/rpcd 与插件安装。
• gateway_missing：CGI 网关不存在或请求方法被网页服务阻止，检查固件是否启用 CGI，并更新插件。
• gateway_unavailable / invalid_response / network_error：网页服务异常、被其他页面接管或浏览器无法连接，请使用原始后台地址重新加载。
• gateway_denied：网页服务返回了没有具体原因的拒绝响应，检查固件网页服务、反向代理或后台访问限制。
• rpc_error：读取服务状态失败，检查 LuCI 权限和插件是否完整安装。

反馈时提供诊断代码、HTTP 状态和固件名称即可，不需要密码或节点链接。OpenWrt、ImmortalWrt、iStoreOS 的定制网页服务可能不同；本插件仍要求现代 LuCI、rpcd 与 CGI 支持，不会绕过登录或把只读账户提升为管理员。

应用时提示失败，刷新后却已生效

旧版通过网页长时间等待内核重载，超过 LuCI 网关期限时，网页可能报错，但后端继续完成。0.6.65 起，应用和启停使用带独立编号的后台任务；页面显示进度，刷新后自动读取该任务的实际结果，不需要重复点击应用。

如果显示“结果暂未确认”，请先重新读取状态并查看运行日志，勿连续提交或删除节点。真正的应用失败会单独显示；后续编辑仍可保持为待应用，不能仅凭“代理运行中”判断新配置已生效。

内存占用为什么看起来很高

先区分整机内存和 NaiLink 进程。部分进程列表显示的 VSZ 或 VmSize 是虚拟地址空间，不能直接当成实际占用。 VmRSS 是进程的驻留内存；整机是否紧张还要结合 MemAvailable、连接数、规则规模和其他服务判断。

在路由器 SSH 中执行以下只读命令，不会重启服务或修改配置：

free -m
grep -E '^(MemTotal|MemAvailable|Cached|SReclaimable):' /proc/meminfo
for name in daed sing-box sing-box-extra mihomo tor; do
  for pid in $(pidof "$name"); do
    echo "$name PID: $pid"
    grep -E '^(Name|VmSize|VmRSS|RssAnon|RssFile):' /proc/$pid/status
  done
done

切换窗口会显示管理服务和当前内核的常驻内存近似合计；共享页可能重复统计。安装了其他内核但没有启用时，它们不会同时作为代理运行。批量节点测试可能短时启动私有进程，任务结束后释放。

若没有 NaiLink 输出，先检查服务是否运行。RssAnon 主要用于观察匿名内存，RssFile 包含驻留的代码与文件映射；透明代理的内核映射等开销不全部计入进程 RSS。 程序安装大小也不等于运行内存。先记录启动后、测试节点后和运行一段时间的数值，再判断是否持续增长。

0.6.22 已将前端资源改为按需索引，减少基础驻留开销。没有用固定小内存上限约束代理核心，也不建议为了降低显示数值而定时重启服务或清空整机缓存。

节点测试超时、失败

先选一条真实节点单独测试。订阅里的“剩余流量”“套餐到期”等信息条目即使被解析为节点，也不适合作为可用线路判断依据。

1. 确认同一条节点现在是否在其他客户端可用。必须是同一个地址、端口和参数，不能只比较协议名。
2. 若两边都失败：优先核查服务商状态、节点有效期、线路、UDP 条件与服务端配置。
3. 若其他客户端可用：核对 NaiLink 导入后是否保留了认证、加密、插件、TLS / SNI、混淆和端口范围。
4. 按错误分类定位：解析失败看 DNS；证书错误看时间、SNI 和证书；被拒绝看端口 / 服务；超时结合线路和服务端日志。

自建 SS 可用而某机场 SS 不可用，只能说明问题并非所有 SS 都失效。机场可能使用不同插件、参数、端口或接入限制；超时本身无法确定是插件还是服务端原因。

批量测试到一半停了

先看是否显示暂停或请求异常。当前队列对临时请求失败会重试，持续失败会明确暂停并保留结果；普通节点不可用本身不会直接终止所有任务。

• 使用继续未完成或重试失败节点，避免重复测试全部节点。
• 按来源分批测试，观察同一时段管理页面和服务是否仍然响应。
• 检查是否刚应用配置、网络断开、LuCI 会话过期，或系统资源不足。
• 若停止后迟迟不返回，记录进度、时间及本次日志，不要只截图一个红色结果。

订阅更新 403、AUTH_FAIL 或没有节点

先在服务商支持的客户端执行本次更新，不要仅凭旧节点仍能连通认定订阅下载正常。403 / AUTH_FAIL 可能涉及订阅凭据、出口授权或服务商规则；不能直接认定是 User-Agent 问题。

默认下载策略是 auto：先尝试系统路径与 dae 路由，失败后读取已运行 PassWall 的本机 SOCKS 出口重试。它不会启动或修改 PassWall，也不会让未获服务商授权的出口自动获得权限。

返回内容若是登录页、HTML 或错误信息，需要先解决下载响应。不要把该响应反复当作节点配置导入；失败更新会保留已有节点。

代理运行中，但不能联网或概况为零

1. 确认数据实际来自连接这台路由器的设备，并重新发起一次访问。
2. 检查群组是否有可用成员、路由是否指向它、配置是否已应用。
3. 检查真实 LAN / WAN 设备绑定，以及是否有其他透明代理同时接管流量。
4. 检查 DNS：节点服务器与业务网站是否都能解析。
5. 查看本次运行日志。Ready、eBPF 加载成功或有连接数，均不能单独证明代理出口可用。

概况统计的是当前实例，重载后会重新累计，空闲时速度为零属正常。若 v0.6.79 在持续传输时仍为零，请记录版本、时间、访问路径和日志。旧版曾有统计来源问题，更新后再验证。

日志中 Netkit 创建失败后回退到 veth，并继续成功启动时，不要仅根据这条警告认定启动失败。应结合实际绑定和访问结果判断。

AdZero 已开启，mihomo 下拦截数仍为零

若请求数增长，并提示命中规则的查询返回 SERVFAIL，应先对比广告样本与正常域名的实际应答。NaiLink 0.6.63 的 mihomo DNS 桥曾把明确拒绝的查询返回为 REFUSED，经 mihomo 后可能变成 SERVFAIL；样本虽没有返回地址，AdZero 也不会将普通 DNS 故障算作拦截。

v0.6.79 修正了这一兼容层：明确命中拒绝策略时返回 NXDOMAIN，真实上游失败仍保持 SERVFAIL。更新后等待 NaiLink 完成重载，再从客户端发起新的查询检查。无需清零统计或增加规则列表；设备缓存、加密 DNS 和未命中规则的广告仍需分别核对。

同一订阅，比其他客户端延迟高或视频卡

先确认两边确实使用同一个节点和入口，再区分首次连接延迟与持续下载速度。测试显示的毫秒数不是带宽，也不是页面完整加载时间。

1. 一次只用一条代理路径：比较 NaiLink 时关闭电脑客户端的系统代理 / TUN；比较客户端时确认其服务器连接没有再经过路由器代理，避免双重代理干扰。
2. 确认实际生效节点：加入群组后等待保存并应用配置，再通过查看生效出口核对结果。自动群组可以更换成员，卡片里有这个节点不代表流量一定使用它。
3. 对齐测试条件：使用同一目标、HTTP 方法、网络和时间段。NaiLink 的首连结果包含建连、代理握手和响应；客户端复用连接的延迟不能与它直接等同。
4. 独立比较传输：用同一视频画质或同一下载文件观察一段时间，记录速度和中断。Wi-Fi、服务器入口、出口线路和 UDP / QUIC 都可能影响播放。
5. 再比较内核或接管模式：每次只改一个选项，检查并切换后重建测试连接。非 TUN 不保证比 TUN 更快，保留实测稳定的选择。

确认只在 NaiLink 上异常时，提供同一节点的对照、实际内核与模式、测试目标、时间和同期日志。不要为降低毫秒数而缩短检测范围、关闭证书验证或清空全部缓存。操作说明见内核切换和群组管理。

同一个美国节点，Gemini 在 NaiLink 上回复更慢

同一个出口节点，电脑和路由器连到它的线路也可能不同。先核对实际使用的节点，再分别记录网页首字节时间和发送消息到出现第一个字的时间。 前者有助于对照线路，后者还受 Gemini 模型和服务端负载影响。比较时用同一台设备、同一账号和模型，各试几次相同的短消息。

对照 NaiLink 时关闭电脑客户端的系统代理和 TUN；对照电脑客户端时，确认它连节点的流量没有再走 NaiLink 的其他代理节点。 可在运行日志中按测试时间核对 Gemini 流量命中的群组及实际节点；查看生效出口可辅助核对已应用的候选节点。

如果路由器直连美国节点不稳定，可以在 dae 上试一条经过中转的线路，并保留原节点供对照：

1. 在节点和订阅 → 导入节点中把 出口节点链接 -> 中转节点链接 作为一条节点链接导入，另填一个便于识别的标签。左边是美国出口，右边是路由器先连接的中转节点。 语法见 dae 代理链说明。
2. 在原来的 AI 或 Gemini 群组中保留原节点，测试新链后再加入该群组并应用配置。 对照时通过日志确认哪条线路实际处理了请求；使用自动选择时，两条线路都有可能被选中。
3. 重新发起连接和对话，对比实际回复时间及稳定性。中转是否更快取决于线路；如果效果不好，移除新增的链并再次应用，即可只使用原来的线路。

如果只想让一台电脑试用，先建立单独的群组，再给该设备添加源 IP 和域名都匹配的规则，并放在会提前匹配的通用规则之前。 规则范围越大，受影响的 Google 服务越多；保留其他设备原有的规则，参见路由设置。

切换后反复提示内核接口异常

先区分代理是否能实际联网和运行概况能否取到统计。旧版把超过 2 MiB 的有效连接列表也当作异常数据，轮询会反复弹窗；这不一定代表代理已经断开。

更新到 v0.6.79 后，sing-box / mihomo 的统计逐条汇总，较大连接列表自动降低采集频率。采集失败时保留上次数据并在运行概况内提示，恢复后自动消除；配置操作的错误仍会正常提示。 统计响应超过 16 MiB、格式错误或超时仍会被拒绝。若持续不可用，提供时间、连接规模与运行日志中的诊断码，无需发送连接明细、节点链接或密码。

应用时移除节点，页面一直等待

0.6.60 及更早版本可能在应用配置时一直持有数据库事务，同时移除群组节点会被该事务阻塞。这与整台路由器死机不同；其他网站和代理可能仍可使用。

0.6.61 改为先读取配置快照、释放事务，再重载内核和记录结果。应用期间成员的“×”及拖动暂时禁用，完成后恢复；另一页面提交的后续编辑仍保留为待应用，不会被本次加载覆盖。

旧版遇到此现象时，不要连续点击应用或反复移除。记录发生时间和日志，保留配置与备份，再按保留数据更新步骤升级。若只有 NaiLink 页面异常，不能仅据此认定路由器或节点服务器崩溃。

切换内核后等待恢复或提示未就绪

先看窗口上方的当前内核、接管方式和后台结果。被高亮的目标尚不代表切换成功；操作中状态和统计可能暂时不可用，先等待完成，再点重新读取状态。

0.6.79 不接受已经超时或取消的启动成功结果，失败清理也有独立时限。若仍无法恢复，使用只读网络诊断并保留错误分类。内核切换会短暂断连，无法把旧浏览器连接无缝迁移；无需把清空浏览器缓存作为常规操作。

首次打开慢，刷新后恢复

间歇性失败可能涉及 DNS 无响应、节点线路、IPv6 或浏览器 QUIC；仅凭刷新后恢复无法确定原因。 v0.6.25 对 tcp+udp DNS 提前尝试 TCP，并让有备用成员的自动群组在 TCP 建连失败时补试一次，减少失败直接传给浏览器的情况。

0.6.79 修复 DNS 桥复用 TCP / TLS 连接被静默丢弃后的等待：只读查询在原期限内最多补发一次同上游、同出口的请求，同时保留原连接的有效响应。它不更换 DNS、不直连绕过代理，也不能修复服务器入口不可达。

想使用备用节点，需要把至少两个可用节点放进同一个群组，选择平滑低延迟等自动策略并应用配置。 固定策略和单节点群组仍使用指定节点；连接开始传输后不会切换或重放数据。不要为了排查同时更改 DNS、IPv6 和路由。

如果升级后仍出现，记录失败时间、使用的节点协议、群组策略，以及同一网络下其他网站的表现；保留发生时的运行日志。 延迟测试成功只能证明测试目标当时可达，不能保证所有网站或 UDP 路径可用。

连接阶段诊断

从 v0.6.28 起，可在高级设置 → 当前配置中临时将日志等级设为 debug，保存并应用后复现一次问题，随后在运行日志中搜索 Connection diagnostic。排查结束后改回 info，减少日志量；应用配置会重载服务。

• phase=dns_bootstrap：启动 DNS 解析器的单次解析，包含尝试次数。
• phase=dns_forward：一次 DNS 转发的总等待时间，包含其连接建立与响应等待。
• phase=route_select：路由及节点选择耗时。
• phase=proxy_connect：节点拨号耗时，attempt=2 表示发生了第二次建连尝试。

elapsed_ms 是该阶段耗时，单位毫秒；result 为 ok、timeout、canceled、closed 或 failed。 DNS 失败警告也包含阶段、耗时和结果分类。诊断不改变原有分流或日志等级，不额外输出节点凭据、完整链接或原始错误正文。已有 Debug 日志仍可能含域名、IP 和节点名称，分享前请脱敏。

这些记录用于定位等待发生在哪一段，不能单独证明某个网站可用，也不测量页面完整加载或浏览器首字节时间。

断网恢复后仍不通

先确认路由器 WAN 已恢复，默认路由与 DNS 正常，再检查代理。当前服务监听 WAN 重新上线事件进行恢复；自定义逻辑上联需核对对应设置，见接口说明。

记录断线、恢复和报错时间。需要手动恢复时可重新应用当前配置，但重载可能中断现有连接；不要一开始就清空节点或重装。32 位实验构建的内核限制与普通断线恢复是两类问题。

反馈问题需要哪些信息

• 插件版本、固件版本、CPU 架构和内核版本。
• 触发步骤、发生时间、错误分类，以及是否可稳定复现。
• 同一条节点在同一网络下的同时对照结果。
• 去除凭据后的本次相关日志；涉及网络时说明 LAN / WAN、其他代理接管状态。

请通过 GitHub Issues 或 Telegram 群组反馈。不要公开订阅链接、完整节点链接、密码、UUID、Cookie 或令牌。

Cloudflare Workers 的请求额度为什么消耗很快？

如果节点用 Workers 中转，正常访问和自动测试新开的 WebSocket 都可能消耗请求额度。多个节点共用一个 Worker，或同一个节点加入多个自动选择群组时，探测也会叠加。可在 Cloudflare 的计费说明 查看请求的计算方式。

NaiLink 识别到 *.workers.dev 中转时，dae 对该节点、sing-box 和 mihomo 对包含它的自动群组， 两轮周期探测之间至少间隔 5 分钟。手动测试和正常访问仍可使用。自定义域名无法自动识别时，可在高级设置的配置中调大「检测间隔」， 并检查群组是否设置了更短的间隔。若额度仍然快速消耗，可在 Cloudflare 后台对照暂停代理前后的请求量， 检查同账号的其他 Worker 和客户端。

节点超时、握手失败怎样区分？

0.6.43 起，三内核手动 HTTP 测试包含完整连接与协议握手，普通节点单次最多等待 8 秒，Tor 等长引导协议沿用原期限；排队和私有内核启动不计入延迟。显示 4000 ms 表示确实花了约 4 秒，不会人为扣减。手动结果不能与自动复用连接的延迟直接等同。

• 节点连接超时：尚未连上节点服务器，先考虑服务器地址解析、线路、端口、防火墙或服务端状态，不能据此判定密码错误。
• TLS 握手超时 / 证书错误：检查 TLS、SNI、证书和服务端；不要统一关闭证书验证。
• WebSocket 握手失败 / 入口网关错误：检查路径、Host 及服务端中转。502/503/504 通常需要服务商检查入口后的上游，修改节点标签不能解决。
• 超时：本次请求未在期限内完成，仍可能是线路抖动、响应过慢或服务端问题。可单独重试，并与另一内核或同网络下的客户端对照。

“添加成功”只说明能解析配置。一个测试网址成功，也不代表所有网站和 UDP 应用都可用。请勿公开订阅地址、节点密码或完整链接。

DNS 桥查询繁忙或复用连接中断

0.6.44 在 NaiLink 的 mihomo DNS 转发层加入有限连接复用，减少反复建立 TCP / TLS 连接。连接按上游和出口隔离，停止内核时全部释放；不新增 DNS 答案缓存，也不改变节点选择、DNS 上游或分流设置。

短时突发允许最多 32 个查询执行、32 个等待，排队和网络交换共用原 6 秒期限。连接已被对端关闭时，只读查询最多按原路由重建一次。0.6.79 还处理复用 TCP / TLS 连接静默无响应的情况：在原期限内最多发起一次同路径备用查询，仍保留慢但有效的原响应，返回后取消并释放未使用的连接。

正常新连接、短期限、DNS 更新和区域传输不主动发起这类备用请求。畸形回复不会靠换个上游继续尝试；证书校验、DNS 上游与代理出口保持原设置。

• dns_overloaded：DNS 查询同时执行及等待的数量已满，检查是否有大量客户端请求或上游长时间无响应。
• dns_queue_timeout：查询尚在等待时已超过期限，检查当前负载与 DNS 上游是否可达。
• invalid_dns_reply：回复身份、问题、内容或大小不符合要求。程序拒绝该回复，不把它当作正常解析。

优化可减少重复握手和短时过载造成的失败；机场入口端口不通、服务端拒绝等问题仍需分别检查线路与服务端。