R4S 全能旁路由配置手册：ImmortalWrt、Nikki、Tailscale、Docker 与内网服务

2026年10月25日网络教程

小型双网口软路由连接家庭、办公室、手机与存储设备的网络主题插画

适用：NanoPi R4S、ImmortalWrt 24.10.6、opkg、fw4/nftables，按 IPv4 家庭网络配置。R2S 可参考操作，固件和内核模块须匹配设备。

优先用 LuCI/iStore 设置；已安装的组件检查后跳过。命令均在 R4S 的 SSH 终端执行，示例地址、账号、设备名按实际替换，不要一次执行全文代码。

项目	地址或设置
Q3000 主路由	192.168.10.1
R4S 旁路由	192.168.10.3
家庭网段	192.168.10.0/24
客户端网关	192.168.10.1
客户端 DNS	192.168.10.3
Nikki DNS	127.0.0.1:1053
Docker 存储	/opt/docker
文件、媒体存储	/mnt/wrt-disk

一、设备分工与接线

text

互联网 → Q3000（192.168.10.1）
           ├─ 电脑、手机、NAS
           └─ LAN → R4S LAN（192.168.10.3）
                       ├─ Nikki：代理、DNS
                       ├─ Tailscale：远程接入、出口节点
                       └─ Docker、Samba、Cloudflare Tunnel

Q3000 负责拨号、DHCP 和方案 B 分流：国内走 WAN，需要代理的流量交给 R4S；R4S 的 WAN 留空。

R4S 自身的出网流量必须经 Q3000 直达 WAN，不能再次转回 R4S。

二、离线定制固件

基础为官方 ImmortalWrt 24.10.6，镜像及根分区扩大到 5 GiB，首次开机通过标准 opkg install 安装原始软件包。

组件	本次预置内容
Nikki	1.26.2，含中文包
Mihomo	1.19.32
Tailscale	1.104.1，GuNanOvO 社区编译精简包
Tailscale 管理页面	Community 4.3.0，含中文包
Nikki 面板	默认 Zashboard cdn-fonts 版
数据	GeoSite、GeoIP、Country、ASN；25 份公共规则参考副本

以上为本次构建版本。刷入介质至少 8GB；Docker 和媒体另需存储空间。

预下载材料：

text

/usr/share/offline-resources/
├── packages/         软件包、依赖
├── data/geodata/     Geo 数据原始副本
├── data/ui/          默认面板原始副本
├── data/rules/       公共规则参考副本
├── manifest.json     来源、版本、校验值
└── SHA256SUMS        校验清单

安装记录：

text

/root/offline-install.log
/root/offline-install-result.txt

首次安装脚本为 /etc/uci-defaults/zzzz-99-install-offline-packages：成功后自动删除，普通重启不重复安装；失败则下次启动重试，跳过已有包、保留数据。

脚本不预设私人 YAML、网络、DNS 或 Tailscale 账号，不修改原始启动脚本；软件包仍按官方流程初始化。

SquashFS 底层只读，删除预置文件不释放底层空间；恢复出厂后会重新执行首次安装。

三、Nikki：安装、导入 YAML、代理和 DNS

3.1 准备与检查

电脑接入管理网络，打开 R4S 后台。本文最终地址为 192.168.10.3；尚未改旁路由时使用实际管理地址。

“状态 → 概览”：确认系统为 ImmortalWrt 24.10，使用 fw4。
“系统 → 软件包 → 已安装”：搜索 Nikki，检查是否已安装。
“状态 → 路由”：检查默认路由；改旁路由后应经 LAN 到 192.168.10.1，不能指向已断线 WAN。

需要命令核对时，下面只查询系统、工具、路由和已安装组件：

cat /etc/openwrt_release
uname -r
command -v opkg
command -v fw4
ip -4 route
opkg list-installed | grep -E '^(nikki|luci-app-nikki|mihomo)'

结果解读：系统应为 24.10.x；工具查询应返回路径，空白表示未找到。包列表显示名称和版本才算已安装；旁路由默认路由应经 LAN 到 .1。

3.2 安装 Nikki：预置版与原生版二选一

本次离线固件： 等待首次安装完成，后台应出现 Nikki。下面核对安装记录、软件包和核心版本：

cat /root/offline-install-result.txt
opkg list-installed | grep -E '^(nikki|luci-app-nikki|mihomo)'
mihomo -v

结果解读：安装记录应成功，包列表包含 Nikki/LuCI，核心能输出版本。原生安装没有离线结果文件，不据此判断安装失败。

原生固件未安装： 按 Nikki 官方方式添加软件源并安装，以下命令需能访问 GitHub 和 Nikki 软件源：

wget -O - https://github.com/nikkinikki-org/OpenWrt-nikki/raw/refs/heads/main/feed.sh | ash
opkg update
opkg install nikki luci-app-nikki luci-i18n-nikki-zh-cn

结果解读：无下载、依赖或安装错误，刷新后台出现 Nikki。报错时先处理，不继续导入配置。

安装后进入“服务 → Nikki”。软件源匹配 24.10，不混装其他内核的 kmod。官方安装说明

只有电脑 Clash 能联网时，开启 Allow LAN，记录 IP 和 mixed port，并在 Windows 防火墙放行可信内网访问。下面让当前 SSH 终端的下载临时借用电脑代理：

# 示例，替换为电脑实际 IP 与端口
export http_proxy='http://192.168.10.100:7897'
export https_proxy="$http_proxy"

结果解读：通常没有输出；随后能下载才说明代理可用。Connection refused 先查 IP、端口、Allow LAN 和防火墙。

再执行下载、安装命令。不支持该代理的下载工具，可改为电脑下载后上传。完成后清除当前终端的临时代理：

unset http_proxy https_proxy

结果解读：通常没有输出，之后不再使用这两项临时代理。

3.3 上传并选择配置

打开“服务 → Nikki → 配置文件”。
上传自己的 .yaml/.yml 文件，确认节点、DNS、规则提供者完整。
回到常规配置，在“配置文件/订阅”选择刚上传的文件。
启用“测试配置”，首次不使用“仅核心模式”。
若使用订阅，填写订阅地址并手动更新一次，确认下载成功；“优先远程”启动时可能重新下载，“优先本地”优先复用已下载文件。

3.4 检查混入配置和控制面板

路径：服务 → Nikki → 混入配置，使用插件正常混入机制：

项目	本文设置
运行模式	规则模式
控制接口/API	`[::]:9090`，仅可信内网使用
API 密钥	使用安装生成的密钥，不能留空；自定义后面板同步修改
UI 路径	`ui`
UI 下载地址	保持 Nikki 默认 Zashboard 地址
允许局域网连接	开启
DNS	启用，监听 `[::]:1053`
DNS 模式	按 YAML；本文方案采用 Fake-IP 时选 Fake-IP
重定向端口	保持默认 `7891`
TUN	开启，设备名保持 `nikki`
IPv6、DNS IPv6	本文未配置 IPv6 分流时关闭

节点、规则和 Geo 地址按现有 YAML 保留；API 和代理端口不映射到公网。

面板目录为 /etc/nikki/run/ui，本次固件已预置默认面板。原生安装首次需联网下载；打不开时检查核心、API、密钥和 ui/index.html。

3.5 设置代理和访问控制

路径：Nikki → 代理配置。

项目	本文设置
启用代理	开启
TCP 模式	Redirect
UDP 模式	TUN
IPv4 代理、IPv4 DNS 劫持	开启
IPv6 代理、IPv6 DNS 劫持	本文 IPv4 方案关闭
路由器代理	开启，让 R4S 自己的下载等流量可分流
局域网代理	开启
局域网入站接口	先选 `lan`；Tailscale 接口建立后增加 `tailscale`
要代理的目标端口	保留默认全端口，除非明确需要限制
保留 IP/内网绕过	保留默认，包括家庭网段和 `100.64.0.0/10`

访问控制保留安装生成的正常规则；自定义后须有启用的允许规则，不要删空列表。未匹配允许规则的流量可能不进入代理。

Tailscale 安装后再补选入站接口，不能只设置 Docker。

3.6 将家庭 DNS 交给 Nikki

确认 Nikki 已启动、DNS 监听 1053，进入“网络 → DHCP/DNS → 转发”，在“DNS 转发”添加 127.0.0.1#1053。

127.0.0.1 是本机，#1053 指 Nikki DNS 端口。客户端访问 R4S 的 53 端口，dnsmasq 再交给 Nikki，由 YAML 决定解析与 Fake-IP；客户端不用填写 1053。

text

客户端 → R4S dnsmasq:53 → 127.0.0.1:1053（Nikki）→ YAML 指定的 DNS

24.10 的“忽略解析文件”位于“Resolv 和 Hosts 文件”页，部分界面需先添加可选项才显示。开启后不再额外读取自动上游 DNS，避免查询绕过 Nikki。 ImmortalWrt 24.10 LuCI 定义

界面没有该项时，用 WinSCP 编辑 /etc/config/dhcp，在现有 config dnsmasq 段补充或修改下面一项，保留其他内容：

text

option noresolv '1'

保存后在“系统 → 启动项”重启 dnsmasq。“忽略 hosts 文件”不是同一项；这里也不会关闭 DHCP。

方案 B：Q3000 下发网关 .1，继续负责分流；下发 DNS .3，让解析经过 Nikki。客户端重新获取地址后生效。

LAN 自定义 DNS 223.5.5.5 是国内可直连上游，供启动和基础解析使用，不是客户端 DNS。Nikki 启动后的系统查询仍取决于本地 DNS 与 YAML 设置，并不保证始终绕过 Nikki。

3.7 启动、选节点、验证

先在网页检查 Nikki 和节点；命令验证需要 curl，未安装时在“系统 → 软件包”安装 curl、ca-bundle。

Nikki 常规设置勾选启用，保存并应用。
打开面板，执行节点测速。
为“默认代理”等实际使用的策略组选择可用节点。
分别测试 R4S 本机和家庭客户端，不能只看面板有节点名称。

下面检查服务、核心进程，以及 R4S 本机国内外 HTTPS 连通性：

/etc/init.d/nikki status
pgrep -af mihomo
curl -I --connect-timeout 8 --max-time 15 https://www.baidu.com
curl -I --connect-timeout 8 --max-time 15 https://www.gstatic.com/generate_204

结果解读：服务应运行，pgrep 应列出 Mihomo。百度返回 HTTP 状态表示国内链路有响应，gstatic 通常返回 204；只有 Connection established 不够，还要看后续响应。超时查链路，解析失败查 DNS，证书错误查时间和证书。

优先在 Nikki“日志”页排查；网页不便查看时，下面各读取最近 40 行插件和核心日志：

tail -n 40 /var/log/nikki/app.log
tail -n 40 /var/log/nikki/core.log

结果解读：持续的 dns resolve failed 查 DNS；timeout 查节点和路由；规则下载失败查 URL。文件不存在时，以本版本网页日志位置为准。

3.8 离线数据和后续更新

运行目录为 /etc/nikki/run/。Geo 与 UI 缺失时由预置副本补齐；MRS 参考副本在 /usr/share/offline-resources/data/rules/，不会自动匹配任意 YAML。

新 YAML 增加的订阅和规则仍可能联网下载。HTTP 规则有缓存时通常复用，按 interval 更新；86400 为一天，不是每次匹配都下载。

四、配置旁路由和方案 B

改动网络前，在“系统 → 备份/升级”生成并下载配置备份，通过本地 LAN 操作；改地址后用新地址重新登录。

4.1 R4S LAN

路径：网络 → 接口 → LAN → 编辑。

项目	设置
协议	静态地址
IPv4	192.168.10.3
掩码	255.255.255.0
网关	192.168.10.1
自定义 DNS	223.5.5.5：国内可直连上游，供系统基础解析；不是客户端 DNS
DHCP	勾选“忽略此接口”
RA、DHCPv6	本文 IPv4 方案关闭

上述设置对应方案 B：

固定 192.168.10.3，让主路由分流规则与客户端 DNS 始终能找到 R4S。
网关 192.168.10.1，让 R4S 的流量经 Q3000 出网；Q3000 必须让 R4S 自身流量直达 WAN，防止循环转发。
223.5.5.5 是国内可直连 DNS，帮助系统启动及基础解析；客户端仍用 R4S 的 .3，不能混填成同一项。
关闭 R4S 的 DHCP，由 Q3000 统一发地址、网关和 DNS，避免抢答。
本文按 IPv4 分流，未配套 IPv6 路由与代理时不额外启用 R4S 的 RA/DHCPv6，避免客户端走另一条未配置的路径。

4.2 停用闲置 WAN

停止 WAN、WAN6，关闭“开机自动连接”，清除 WAN 网关，不让 WAN 提供默认路由。不要让 LAN、WAN 同属 192.168.10.0/24 并竞争出网方向。

先在“状态 → 路由”检查，或用下面两行查询默认路由和实际出口：

ip -4 route
ip -4 route get 223.5.5.5

结果解读：应有 default via 192.168.10.1 dev br-lan；出口查询应经 .1、LAN，源地址为 .3，设备名按实际。仍走断线 WAN 时先修正路由。

4.3 DNS 与主路由

确认 Nikki 监听 1053，在“DHCP/DNS → 转发”填 127.0.0.1#1053，把查询交给本机 Nikki；“忽略解析文件”按 3.6 设置。

Q3000 开启 DHCP，下发网关 .1、DNS .3，并保留 R4S 地址。客户端仍经主路由分流，DNS 交给 Nikki；R4S 自身流量直接走 WAN，避免循环。

已有方案 B 规则检查后保留。验收时先停用客户端自设公共 DNS/浏览器加密 DNS，避免走不同解析路径。

五、Tailscale：完整安装、登录、出口与子网配置

目标：手机使用流量连接后，可以访问 192.168.10.x 家庭设备、Docker 服务，也可选择经过 R4S 的 Nikki 上网。

5.1 准备：先确认 R4S 自己能联网

电脑接管理网络，用本地 IP 登录 R4S，不通过正在配置的 Tailscale 操作。

“状态 → 路由”：旁路由默认路由应经 LAN 到 192.168.10.1。
“网络 → 诊断”：测试国内域名解析和 Ping；Nikki 页面检查节点是否可用。
“系统 → 备份/升级”：生成并下载配置备份。

有异常时，用下面命令检查路由、DNS 和国外 HTTPS。curl 未安装时在软件包页面补装 curl、ca-bundle：

ip -4 route
ip -4 route get 223.5.5.5
nslookup www.baidu.com 223.5.5.5
curl -I --connect-timeout 8 --max-time 15 https://www.gstatic.com/generate_204

结果解读：应有 default via 192.168.10.1 dev br-lan；出口查询应经 .1、LAN，源地址为 .3，设备名按实际。仍走断线 WAN 时先修正路由。 nslookup 应有域名的回答地址，不只显示 DNS 服务器；HTTPS 目标通常返回 204，超时查节点和路由。

修正闲置 WAN 默认路由或 LAN/WAN 同网段问题后，再配置 Tailscale。

5.2 检查安装；已预置则不重装

先在已安装软件包中搜索 tailscale，网页查看版本。下面两行用于核对组件和核心版本，不执行安装：

opkg list-installed | grep -E '^(tailscale|luci-app-tailscale|luci-i18n-tailscale)'
tailscale version

结果解读：应有主程序、Community 页面和中文包；核心应输出版本，本次预置为 1.104.1。无包输出或 command not found 表示对应组件未安装或命令不可用。

离线固件已包含这三个组件，检查后跳到 5.3。原生固件未安装时：

确认系统为 24.10/opkg、架构为 aarch64_generic。
“系统 → 软件包”：更新列表，依次安装 ca-bundle、ip-full、kmod-tun。内核模块必须与当前固件匹配，不强制安装。
在电脑下载本次采用的三个软件包：

组件	版本文件
主程序	`tailscale_1.104.1_aarch64_generic.ipk`
Community 页面	`luci-app-tailscale-community_4.3.0-r1_all.ipk`
中文包	`luci-i18n-tailscale-community-zh-cn_0.260928.31178_all.ipk`

以上是本次采用的版本，也可选择系统源主程序，版本可能不同。主程序社区发布页 Community 发布页

在“系统 → 软件包 → 上传软件包”依次上传并安装主程序、Community 页面、中文包；核对架构和发布来源，不混入旧版 asvow 包。
刷新后台，确认出现 Tailscale 页面及版本；提示依赖缺失时，先安装对应系统软件源中的依赖，不忽略报错继续。

不使用 --force-overwrite，也不叠装旧版 LuCI 插件。

5.3 首次启动与登录

“系统 → 启动项”：找到 tailscale，启用开机启动并启动服务。
打开“VPN → Tailscale → 常规设置”，勾选服务开关，保存并应用。
进入“账号设置”，自定义服务器、认证密钥留空，使用官方账号服务。
点一次登录，打开这次生成的链接，完成账号登录和设备授权。
网页提示成功后返回 R4S，刷新页面，确认“正在运行”并记录本次 100.x.x.x 地址；不要反复点登录或批准重刷前的旧设备。

网页状态不明确时，下面查询连接状态与本机 Tailscale IPv4 地址：

tailscale status
tailscale ip -4

结果解读：应有节点列表和本机 100.x 地址。Logged out/NeedsLogin 查登录授权；无法连接守护进程查服务。重刷后地址可能变化。

5.4 Community 设置逐项填写

先采用“远程访问家里＋R4S 提供出口”的基础配置，暂不接收其他地点子网。

项目	建议设置	作用
服务开关	勾选	运行服务
防火墙模式	nftables	匹配 fw4
接受路由	仅手机访问家里可不勾；家里与公司互通时两端均勾选	让本机采用其他 Tailscale 路由器发布的子网路径，详见下方例子
通告出口节点	勾选	让手机选择 R4S 出口
允许局域网访问	不勾选	R4S 自己使用其他出口时保留它的本地 LAN；不是开放家庭子网的开关
启用 Web 界面	不勾选	额外管理页；精简核心可能未包含此功能
禁用 SNAT	先不勾，保留现有可用的 NAT 方式；需要真实来源时再按 8.5 规划	不勾时隐藏远端原始 IP，简化回程；勾选后必须配齐回程路由
开启防护/Shields Up	不勾选	开启会阻止发往本机的 Tailscale 入站连接
Tailscale SSH	不勾选	普通 SSH 仍可用；这项是 Tailscale 管理的 SSH
DNS 模式	已禁用	R4S 不接受 Tailnet DNS，继续用 Nikki
禁用防火墙配置	不勾选	允许 Tailscale 管理自身规则
启用节点中继	不勾选	本机充当 peer relay；不影响使用官方 DERP
出口节点	无	R4S 不借用其他设备上网
通告路由	192.168.10.0/24	发布家庭网段

主机名、状态文件、端口和日志保持默认。MagicDNS 接受 Tailnet DNS，OpenWrt 转发主要用于 .ts.net；本文按 IP 访问，DNS 保持禁用。

点击保存并应用。下面区分三个容易混淆的选项：

通告路由：告诉其他设备“家里 192.168.10.0/24 可以从我这里到达”。
接受路由：本机采用别人发布的子网路径，例如“去公司 192.168.110.0/24，走公司的 Tailscale 路由器”。
通告出口节点：允许手机把互联网流量经 R4S 上网，与上面两项不是同一个功能。

例子：家里＋公司＋手机流量。 家里网段 192.168.10.0/24，公司网段 192.168.110.0/24；两边主路由、旁路由结构可以相同，IP 网段必须不同。

设备	通告路由	接受路由	目的
家里 R4S	192.168.10.0/24	勾选	发布家里网段，并学习去公司的路径
公司 Tailscale 路由器	192.168.110.0/24	勾选	发布公司网段，并学习去家里的路径
手机	不发布子网	Android/iOS 通常自动使用已批准的子网路由	流量状态下访问家里和公司，不要求两边都设为出口

例如家里电脑访问公司 NAS 192.168.110.20：主路由先交给家里 R4S，R4S 接受公司路由后再发往公司；反方向同理。

只让手机访问家里，R4S 可不接受路由；两地内网双向互通，两端都勾选，再配置参与设备的路径与权限。公司主路由不能设置时，用设备自身路由、Tailscale 客户端或调整网关，详见第八部分。官方路由说明

5.5 系统转发：正常已开启就不用修改

系统转发负责把数据从 Tailscale 转到 LAN/出口；防火墙负责是否放行，两者都要满足。

OpenWrt 24.10 默认已开启 IPv4/IPv6 转发。出口、子网正常时不用重复设置；仅在提示 forwarding 未开启或转发异常时检查。 OpenWrt 24.10 默认配置

下面只查询转发状态，不修改设置：

sysctl net.ipv4.ip_forward
sysctl net.ipv6.conf.all.forwarding

结果解读：= 1 为开启，= 0 为关闭。IPv4 子网需第一项；提供出口时按要求核对两项。

检查为 0 才修改。LuCI 没有相应入口时，用 WinSCP 编辑 /etc/sysctl.conf，保留原内容，将缺失项补齐或由 0 改为 1，避免重复定义：

text

net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1

保存后执行下面命令应用设置，再查询确认；也可重启后检查：

sysctl -p /etc/sysctl.conf

结果解读：应无报错，复查目标值为 1。该命令会应用文件内其他设置，执行前一并核对。

无需额外创建 99-tailscale-forwarding.conf；IPv6 转发开启，也不代表家庭 IPv6 已配置完成。

5.6 创建 tailscale 接口和防火墙区域

首次点击 Community“自动配置防火墙”，保存后检查；已有正确配置不重复创建。

网络 → 接口，应有：

项目	值
逻辑接口名	tailscale
协议	不配置协议/Unmanaged
Linux 设备	tailscale0
所属防火墙区域	tailscale

网络 → 防火墙，核对：

tailscale 区域：入站、出站、转发允许；勾选该区域的 MTU 修正，按实际保留 IP 伪装。
转发：tailscale → lan；需要家庭设备主动访问远端时还有 lan → tailscale。
有 Docker 时核对 tailscale → docker、lan → docker；宿主机端口映射仍需 Dockerman 允许接口。
本文可信 LAN 旁路由使用“常规设置 → Forward → ACCEPT”。有隔离 VLAN/访客网时，改为精确区域放行，不能一概全部接受。

本方案出口经 LAN 到 Q3000，不能只放行 tailscale→wan；主路由 WAN 入站策略保持原设置。

5.7 让远端流量进入 Nikki

打开 Nikki → 代理配置 → 局域网代理：启用，入站接口保留 lan，增加逻辑接口 tailscale，保存并应用。

界面明确要求设备名时填 tailscale0。保留内网与 100.64.0.0/10 绕过，避免将 Tailscale 地址送给公共代理。

不使用 Nikki 时无需此步；需要手机经家里的 Nikki 分流时必做。

5.8 Docker 服务访问：不要漏掉允许接口

已安装 Docker 时：Docker → 配置 → 访问控制 → 允许的访问接口，保留 br-lan，增加设备名 tailscale0，保存并应用。

在 Docker 容器详情确认运行状态与端口映射，例如 4533:4533；访问 http://192.168.10.3:宿主机端口。

尚未安装 Docker 就暂不设置；以后安装时再补上接口与区域转发。

5.9 云端批准出口和家庭子网

进入 Tailscale 设备后台：

找到本次 R4S，核对 100.x.x.x。
“⋯ → Edit route settings”。
勾选 Use as exit node 和 192.168.10.0/24，保存。
若账号修改过 ACL/Grants，允许相应用户访问家庭网段，并使用 autogroup:internet 出口。

批准路由和访问权限是两件事。官方子网说明

5.10 DNS 与手机配置

R4S：Community DNS 模式为“已禁用”；Nikki DNS 监听 1053，dnsmasq 转发 127.0.0.1#1053。
手机：开启 Tailscale，通常保留接受 Tailscale DNS；关闭 Wi-Fi，使用流量。
手机“出口节点”选择 R4S。仅访问家庭子网，不一定要选择出口。
手机不同时运行另一款 VPN。先按 IP 测试，不依赖局域网设备自动发现。

text

R4S：       http://192.168.10.3
Q3000：     http://192.168.10.1
容器：      http://192.168.10.3:发布端口

使用出口时默认经出口处理 DNS。需要统一上游时，再在后台“DNS → Nameservers”添加可达解析器，按需开启 Use with exit node 和 DNS 覆盖；混填国内外 DNS 不等于自动分流。

5.11 保存、服务刷新与验收

保存并应用后，在 Tailscale 页面确认正在运行、IP 正确；手机使用流量，依次访问家庭设备、Docker 端口、国内网站和代理网站。

异常时，下面核对节点、本机地址与普通/Tailscale 路由表：

tailscale status
tailscale ip -4
ip -4 route
ip -4 route show table 52

结果解读：100.x 应与网页一致，普通默认路由仍走 .1；接受并批准公司路由后，表 52 应包含公司网段。未接收公司路由时不要求有该条目。

设置未生效时，在本地管理页的“系统 → 启动项”重启 tailscale；若列出 tailscale-settings，再重启它。期间 Tailscale 会断开。

仍需整机重启才能恢复时保留日志排查。MASQ、41641 映射和直连检测见第七部分，均非无条件必做。

六、Tailscale、Nikki、Docker 三项关键配置

6.1 Nikki 入站增加 Tailscale【远端流量使用 Nikki 必做】

路径：服务 → Nikki → 代理配置 → 局域网代理。

开启局域网代理。
入站接口保留 lan，增加 tailscale。

Nikki 通常选择逻辑接口 tailscale；对应设备为 tailscale0。列表没有时，在“网络 → 接口”添加：

项目	值
名称	tailscale
协议	不配置协议／Unmanaged
设备	tailscale0
防火墙区域	tailscale

也可由 Community“自动配置防火墙”创建；只有明确要求设备名时才填 tailscale0。

保留 Nikki 对 100.64.0.0/10、192.168.0.0/16 等内网目标的绕过，避免将 Tailscale 和家庭设备连接送进代理节点。

6.2 防火墙转发【本文旁路由方案必做】

路径：网络 → 防火墙 → 常规设置。

text

转发（Forward）：接受（ACCEPT）

保存并应用，同时核对区域转发：

方向	用途
tailscale → lan	远程访问家庭设备，出口经 LAN 到 Q3000
lan → tailscale	本地设备主动访问远端网络
tailscale → docker	远程访问桥接容器
lan → docker	家庭设备访问桥接容器

Forward=ACCEPT 仅用于本文可信 LAN 旁路由。访客网、隔离 VLAN 或 WAN 上联按区域放行，不将主路由 WAN 入站一并放开。

6.3 Docker 允许 tailscale0【远程访问 bridge 容器必做】

安装 Docker 后进入：Docker → 配置 → 访问控制 → 允许的访问接口。

保留原有接口，加入：

text

br-lan
tailscale0

这里填写设备名 tailscale0，与 Nikki 的逻辑接口 tailscale 区分。保存并应用；端口映射和转发也必须正确。

host 网络不经过相同网桥路径；若界面显示“阻止接口”，确认所需接口未被阻止。 Dockerman 界面定义

七、手机使用、DNS 和可选优化

7.1 手机连接

手机关闭 Wi-Fi、使用流量，连接同一账号网络。如需经家里上网，在手机“出口节点”选择 R4S。

text

R4S：       http://192.168.10.3
Q3000：     http://192.168.10.1
Navidrome： http://192.168.10.3:4533
其他容器：  http://192.168.10.3:已发布端口

7.2 DNS：不把覆盖当成必做

R4S 的 Community DNS 保持“已禁用”。
手机通常保留使用 Tailscale DNS。
使用出口时，默认通过出口处理 DNS；正常访问不用额外强制覆盖全账号 DNS。

需要统一上游时，在“DNS → Nameservers”添加可达解析器并按需开启 Use with exit node；先选一种上游验证。

Override DNS servers/local DNS 影响接受 Tailnet DNS 的客户端，按需开启。混填国内外 DNS 不会自动分流。官方 DNS 行为

7.3 Tailscale-MASQ【可选】

默认 SNAT 通常已处理回程；本次实测禁用额外 MASQ 仍能访问，正常时不添加。

仅在确认存在回程问题时，在“网络 → 防火墙 → NAT 规则”添加：

项目	值
名称	Tailscale-MASQ
地址族	IPv4
协议	任意
出站区域	lan
源地址	100.64.0.0/10
目标地址	192.168.10.0/24
操作	MASQUERADE

该规则仅处理 Tailscale IPv4→家庭子网，不代替两地路由设计。互联网出口 NAT 由 Tailscale 正常规则处理。

7.4 UDP 41641 映射【可选】

Q3000：策略中心 → NAT → 端口映射。

项目	值
名称	Tailscale-R4S
协议	UDP
外网接口	wan1
外网端口	41641
内网地址	192.168.10.3
内网端口	41641
端口回流	保持默认，通常不需要

映射用于增加直连机会，不是必需。未映射也可能打洞，失败可走 DERP；上游 NAT/CGNAT 下单配 Q3000 不保证直连。避免端口冲突，无需一律关闭 UPnP。

7.5 直连与 MTU

下面检查活动连接、NAT/UDP 环境及到手机的路径。最后一行先换成手机实际 100.x 地址：

tailscale status --active
tailscale netcheck
tailscale ping 手机的Tailscale地址

结果解读：direct 为直连，relay/DERP 为中继；UDP=true 不保证直连。节点 ping 通后，仍需测试目标服务端口。

MTU 异常时，在 tailscale 防火墙区域启用“MSS 钳制/MTU 修正”；已有正确设置不重复添加，也不照搬 eth0 临时规则。

八、家里、公司、手机互通：公司主路由不能设置时怎么办

8.1 先分清“哪些设备能互通”

家里主路由可配置；公司品牌路由不支持静态路由、由光猫拨号。公司侧可保持现状，以下情况仍能互通：

手机安装 Tailscale，通过两地子网路由访问家里和公司。
公司电脑本身安装了 Tailscale，直接获得去家里的路由。
公司需要互通的设备已把网关指向公司 Tailscale 旁路由。
默认 SNAT 让公司普通设备能直接回复从旁路由转来的访问。

手机访问正常，不代表每台未配置的公司设备都能主动访问家里。先区分测试设备、是否安装 Tailscale，以及它的实际网关。

8.2 两台 Tailscale 路由器的共同设置

示例：家里 192.168.10.0/24、R4S 192.168.10.3；公司 192.168.110.0/24、Tailscale 旁路由 192.168.110.3。公司地址按现场替换，两地网段不能重复。

项目	家里	公司
通告路由	192.168.10.0/24	192.168.110.0/24
接受路由	勾选	勾选
禁用 SNAT	先不勾，保留现有正常 NAT 方式	先不勾，减少回程要求
出口节点（使用别人出口）	无	无
通告出口节点	手机需要经家里上网时勾选	按需，与子网互通分开

两端加入同一 Tailnet并批准各自子网；防火墙放行 LAN↔Tailscale，Nikki 保留私网绕过。Tailnet 限制过权限时，补充相应用户、设备和网段的授权。

本节保留 SNAT，目标通常看到本地旁路由的来源地址，回程简单，但不保留远端真实 IP。需要真实来源时再按 8.5 规划。

8.3 手机访问两地：公司主路由不用加静态路由

手机用流量开启 Tailscale，先不选出口，分别访问两地服务 IP。已批准的子网路由负责去程，默认 SNAT 帮助回程。

经家里上网时再选 R4S 出口；只访问子网，不需要公司提供出口或光猫映射端口。

8.4 两地普通设备主动互访：给参与设备一条正确路径

设备情况	如何设置
设备自身已安装 Tailscale	使用它收到的已批准子网路由；Linux 客户端需启用接受路由
家里普通设备默认网关为 Q3000	在 Q3000 添加到公司网段的静态路由，下一跳为家里 R4S `.3`
公司主路由无法设置	不改它；在需要互通的公司电脑/NAS上配置到家里网段的路由，下一跳为公司旁路由
设备页面只能设置默认网关	可将该设备网关改为公司旁路由；公司旁路由自身仍以上游品牌路由为网关，DNS按现有可用配置保留

家里 Q3000 静态路由示例：目标 192.168.110.0、掩码 255.255.255.0、下一跳 192.168.10.3、接口 LAN。公司若采用设备自己的路由，目标为 192.168.10.0/24、下一跳 192.168.110.3，在该设备的网络/路由页面设置。

公司电脑若仍将请求交给不会转向旁路由的品牌路由，仅勾接受路由不能改道。只需部分设备互通时，只配置这些设备；已有正常路径则保留。

8.5 何时才禁用 SNAT

需要真实来源 IP 或按源网段授权时，再使用保留来源方案：两端接受路由、禁用 SNAT，并补齐对方子网及必要 Tailscale 地址的回程和权限。

公司主路由不能加路由，就由参与设备的路由或网关补齐；不能只关 SNAT。保留来源时也应避免额外 MASQ 改写地址，已有正常 NAT 方案无需切换。官方站点互联要求

8.6 验收方向

分别测试手机→家里、手机→公司、家里普通设备→公司、公司普通设备→家里，访问实际服务端口。记录网关及客户端情况，不只靠手机成功判断双向互通。

九、Docker：分区、防爆锁、挂载与安装

流程：创建 10GB 分区 → 挂载前加锁 → 按 UUID 挂载 → 重启检查 → 安装 Docker。剩余空间在 Samba 章节处理。

9.1 安装 DiskMan 并创建 Docker 分区

确认 R4S 能联网。已有 Docker 时先停止 dockerd，备份容器数据；不要在已有挂载上直接加锁或重新格式化。
“系统 → 软件包”更新列表，安装 DiskMan（luci-app-diskman）；按依赖提示补齐 block-mount、e2fsprogs、kmod-fs-ext4。
“系统 → 磁盘管理”核对存储卡/硬盘容量和设备名，保留系统启动、根分区及 overlay。
在未分配空间创建一个约 10GB 的 Docker 分区，格式化为 ext4；记录设备名与 UUID。已有正确分区不再格式化。
此时先不挂载到 /opt/docker，先完成下面的防爆锁。

9.2 核心：chattr +i 系统盘防爆锁

磁盘未挂载时，/opt/docker 是系统盘目录，Docker 可能写满系统盘。先锁住这个空入口；正常挂载后由数据分区覆盖，Docker 使用分区内的目录。

下面保留原代码，依次创建入口、安装工具和加锁。必须在挂载前、空目录上执行；已挂载时会锁到数据分区本身，不能照做：

# 1. 创建入口文件夹
mkdir -p /opt/docker

# 2. 安装锁定工具
opkg update && opkg install chattr

# 3. 锁定系统盘坑位
chattr +i /opt/docker

结果解读：成功通常无输出；Operation not supported/permitted 表示加锁失败。部分文件系统不支持该属性，需先核对；它只保护未挂载入口，不保证运行中掉盘也安全。

加锁后、挂载前，用下面命令查属性；没有 lsattr 时先在软件包页安装：

lsattr -d /opt/docker

结果解读：应有 i 标记。挂载后查到的是数据分区目录，不能据此判断底层锁失效；Docker 运行时不要为查锁强制卸载。

9.3 按 UUID 精准挂载

“系统 → 挂载点 → 添加”：

项目	设置
启用	勾选
UUID	刚创建的 10GB Docker 分区
文件系统	ext4
挂载点	/opt/docker
作为根文件系统	不勾选

全局设置：关闭“自动挂载未配置分区”，开启“自动挂载已配置分区”，保存并应用，让分区按 UUID 和固定路径挂载。

9.4 重启后验证挂载

在“系统 → 重启”重启后，执行下面命令确认分区实际挂载：

df -h | grep /opt/docker

结果解读：应有实际分区挂在 /opt/docker，容量约 10GB，设备名按现场。无输出、容量或路径错误时先修复，不安装 Docker/拉镜像。该查询只验证挂载，加锁另看属性。

9.5 用原安装命令安装 Docker

确认挂载正确后，使用原命令更新列表并安装 Docker 管理页和中文包：

# 更新并安装 Docker 管理插件及中文语言包
opkg update
opkg install luci-app-dockerman
opkg install luci-i18n-dockerman-zh-cn

结果解读：无依赖、内核或空间错误。若页面提示缺少引擎，在软件包页补装 dockerd、docker，不忽略安装报错。

在“Docker → 配置”核对根目录 /opt/docker；不一致时先停 dockerd 再改。“系统 → 启动项”启用并启动 dockerd。已有容器先迁移数据，改路径不会搬迁。

以下只读命令查看引擎实际使用的数据根目录：

docker info --format '{{.DockerRootDir}}'

结果解读：应为 /opt/docker；其他路径先改正。Cannot connect to the Docker daemon 表示引擎未运行或连接失败，检查启动项和日志。

9.6 打通访问接口与防火墙

Docker → 配置 → 访问控制：保留 br-lan，远程访问时增加 tailscale0；若版本显示“阻止接口”，则确认这两个接口未被阻止。保留 Unix socket，不开放无认证的 TCP 2375。

网络 → 防火墙 → 常规设置：本文可信 LAN 旁路由按原方案将 Forward 设为 ACCEPT，并核对 lan → docker、tailscale → docker 所需转发。访客网/隔离网络按区域精确放行，不将主路由 WAN 入站全部放开。

保存并应用，必要时通过“系统 → 启动项”重启 dockerd；已有容器会短暂中断。

9.7 容器安装后的检查

容器镜像匹配 ARM64，使用固定持久目录，明确填写“宿主机端口:容器端口”，设置合适的自动重启策略。优先在 Docker 容器详情看状态、端口和日志。

网页不便查看时，以下只读命令分别列出运行容器、端口映射和最近 50 行日志；先将“容器名”替换为实际名称：

docker ps
docker port 容器名
docker logs --tail 50 容器名

结果解读：应为 Up；如 4533/tcp -> 0.0.0.0:4533，访问 R4S 的 4533 端口，0.0.0.0 不是浏览器地址。host 网络可能没有端口映射；日志报权限、端口占用或反复重启时按错误排查。

先在家里访问 http://192.168.10.3:宿主机端口，再用手机流量＋Tailscale 访问相同地址。原流程对照

十、Samba 文件共享

沿用原文流程：安装 Samba → 创建用户 → 创建并挂载剩余空间 → 网页设置共享 → 修正权限。挂载路径统一使用 /mnt/wrt-disk。

10.1 安装 Samba

进入“系统 → 软件包”，更新软件列表，安装 Samba4 服务、管理页面及中文包：

samba4-server
luci-app-samba4
luci-i18n-samba4-zh-cn

安装完成后刷新后台，确认“服务 → 网络共享（Samba）”入口出现。已经安装则不用重装。

10.2 SSH 创建用户

下面保留原文命令：安装用户管理工具，创建不允许 Shell 登录的 sirenyan 用户，再设置 Samba 登录密码。

# 1. 安装工具
opkg update && opkg install shadow-useradd

# 2. 创建用户（不创建家目录，禁止 Shell 登录）
useradd -M -s /bin/false sirenyan

# 3. 设置 Samba 密码
smbpasswd -a sirenyan

结果解读：工具安装应无报错；设置密码时按提示输入两次自己的 SMB 密码，输入过程不显示字符。若提示用户已存在，跳过创建用户这一行，直接设置 Samba 密码。

这里的密码用于文件共享登录，与路由器 root 登录密码分开设置。

10.3 创建剩余磁盘空间并挂载

打开“系统 → 磁盘管理（DiskMan）”，确认选中正确的系统卡或硬盘。
保留系统分区和前面已经创建的 Docker 分区，只将剩余的未分配空间创建为新分区，并格式化为 ext4。已有数据分区不重新格式化。
打开“系统 → 挂载点 → 添加”，选择刚创建分区的 UUID，挂载点填写 /mnt/wrt-disk，勾选启用；不勾选“作为根文件系统”。
保持“自动挂载已配置分区”开启、“自动挂载未配置分区”关闭，保存并应用。
确认该分区已挂载，容量与剩余分区一致后，再继续设置共享。

需要命令核对时，下面只检查挂载点和容量，不修改分区：

df -h | grep /mnt/wrt-disk

结果解读：应看到实际分区设备、分区容量及挂载点 /mnt/wrt-disk。没有输出表示尚未挂载，不要继续往这个目录写文件或执行权限修正。

10.4 网页设置共享目录

进入“服务 → 网络共享（Samba）”，添加或编辑数据盘的共享目录：

设置项	填写内容
共享名称	wrt-disk
路径	/mnt/wrt-disk
允许用户（Allowed users）	sirenyan
只读	取消勾选，允许上传和修改
可浏览	勾选
允许访客	取消勾选，使用账号密码访问
强制 Root	取消勾选，使用 sirenyan 的权限

其他项目保持默认，保存并应用。不额外设置创建掩码、目录掩码或强制用户。

10.5 权限修正【重点】

如果账号能够登录，但无法上传、修改或删除文件，按原文方法修正权限，不通过勾选“强制 Root”解决。

先确认 /mnt/wrt-disk 已正确挂载，且盘内是这个用户管理的普通共享文件。下面两行将共享目录及其内容的所有者改为 sirenyan，并赋予所有者读写权限：

# 将文件夹及其内部所有文件的所有者改为 sirenyan
chown -R sirenyan:sirenyan /mnt/wrt-disk
chmod -R 755 /mnt/wrt-disk

结果解读：成功通常没有输出；之后重新连接共享，sirenyan 应能够读写。若提示用户或组不存在，先核对前面的账号创建是否成功，不把报错当作已经修好。

-R 会修改整个共享盘。已有容器数据库或其他用户的专用目录时，不对整盘执行；Docker 仍使用独立的 /opt/docker 分区。

10.6 Windows 连接与验证

在“系统 → 启动项”确认 samba4 已启用并启动。Windows 资源管理器地址栏输入下面的共享地址，不是在浏览器中输入：

text

\\192.168.10.3\wrt-disk

地址开头是两个反斜杠，IP 与共享名之间是一个反斜杠。使用 sirenyan 和 Samba 密码登录，测试新建、修改、删除文件。

若 Windows 一直使用旧账号，在“凭据管理器 → Windows 凭据”删除该地址对应的旧凭据，断开原有共享连接后重新登录。最后重启 R4S，确认磁盘自动挂载、共享仍可读写。

十一、iStore 与首页：完整安装

11.1 准备

确认为本文 opkg 系统，R4S 自己能联网。后台已有 iStore、首页且能正常打开就不重装；缺少哪个只补哪个。下载失败先查路由、DNS 或临时代理，不更换整套系统软件源。

11.2 安装商店

下面的命令更新软件列表，将 LinkEase 安装脚本下载到临时目录并执行，用于安装 iStore 及其配套软件源；后台已有正常 iStore 时跳过：

opkg update || exit 1
cd /tmp
wget -O istore-reinstall.run https://github.com/linkease/openwrt-app-actions/raw/main/applications/luci-app-systools/root/usr/share/systools/istore-reinstall.run
chmod 755 istore-reinstall.run && ./istore-reinstall.run

结果解读：安装无错误，刷新后出现 iStore。下载出文件不代表安装成功，失败时不执行残缺脚本。

此脚本安装 iStore 及配套软件源。 LinkEase 安装脚本

11.3 安装首页和中文包

优先在 iStore 搜索“首页/QuickStart”并安装；已安装则跳过。没有对应入口时，以下命令通过 iStore 软件源安装首页和中文包：

is-opkg update
is-opkg install luci-app-quickstart luci-i18n-quickstart-zh-cn

结果解读：应成功安装首页及中文组件，刷新后台有对应入口；command not found 表示 iStore 安装未完成，先修复商店。

商店和首页是不同组件，确认首页包及中文包都已安装。

11.4 网页设置与验证

浏览器退出后台再登录，或强制刷新。
确认出现 iStore 和首页入口，打开能显示状态。
首页仅作状态、快捷入口；不要用网络向导重新覆盖已完成的方案 B。
中文没显示，核对 LuCI 语言和中文包。
架构不匹配则检查包与系统版本，不使用强制忽略架构安装。

如需进一步核对，在“系统 → 软件包 → 已安装”搜索 luci-app-store、luci-app-quickstart 和首页中文包。

十二、Navidrome：iStore 安装与音乐配置

12.1 一键安装

iStore 搜索 Navidrome 并安装，安装完成后打开对应配置页面，不再手动重复部署同名 Docker 容器。前提是 Docker 已可用、数据盘已按 UUID 自动挂载；未完成时先在 Docker、磁盘管理页面完成这两项。

12.2 设置音乐和数据目录

在 Navidrome 插件页面填写，字段名称以实际插件为准：

项目	示例
配置/数据目录	/opt/docker/appdata/navidrome
音乐目录	/mnt/wrt-disk/music
Web 端口	4533；被占用则换未占用端口
自动启动	开启

数据目录保存数据库、账号和设置；音乐目录保存音频。数据库放在 /opt/docker/appdata/navidrome，避免被整盘 Samba 共享。确认挂载后再建目录，插件未自动创建时用 WinSCP 创建。

启动后在 Docker 容器详情核对：数据目录→/data、音乐目录→/music、宿主机端口→容器 4533。由插件生成映射，不另建同名容器。

12.3 导入音乐和权限核对

通过 Samba 将音乐复制进数据共享的 music 子目录；例如 \\192.168.10.3\wrt-disk 下的 music。
Navidrome 需要对数据目录有写权限，对音乐文件有读权限，对上级目录有执行/穿越权限。
一键安装可能使用不同运行用户，不默认改成 sirenyan。先在 Docker 容器详情核对用户/UID，或查看插件说明；自定义了 UID/GID 时，须与磁盘权限匹配。
若权限报错，只修正实际数据/音乐目录；Samba 的专用共享用户和 Navidrome 的运行用户可能不同，不能对整张盘执行递归改权限，也不用 777 解决。

只有权限报错、网页又看不到运行身份时，再用下面命令查用户。将 navidrome 换成实际容器名：

docker inspect --format '{{.Config.User}}' navidrome
docker exec navidrome id

结果解读：inspect 显示设定用户，id 显示实际 UID/GID，应与目录权限对应。空值表示使用镜像默认身份；容器不运行或没有 id 时，看配置和日志，不直接改整盘所有权。

12.4 首次登录与扫描

浏览器打开 http://192.168.10.3:4533，若修改了宿主机端口则用新端口。
首次创建 Navidrome 管理员账号；它独立于路由器账号和 Samba 账号。
在页面执行扫描或等待自动扫描，确认曲库出现并测试播放。
在插件页面确认自动启动，重启后检查曲库、账号仍在；不以删除数据库来解决权限问题。

12.5 Tailscale 访问

Docker → 配置 → 允许访问接口：保留 br-lan，增加 tailscale0；防火墙核对 tailscale → docker。R4S 的家庭子网需已通告并在 Tailscale 后台批准。

手机使用流量，开启 Tailscale，访问同一地址 http://192.168.10.3:4533。音乐客户端填此服务器地址和 Navidrome 账号密码；只访问曲库不强制选择出口节点。

12.6 常见问题检查顺序

页面打不开：插件是否启动 → Docker 容器状态 → 实际宿主机端口。
曲库为空：音乐目录映射 → 文件位置 → 读取/目录穿越权限 → 扫描日志。
容器退出：插件和 Docker 日志中的 /data 写权限、磁盘挂载、端口占用。
本地正常、流量访问失败：Tailscale 子网批准 → Docker 允许接口 → 防火墙及 Tailnet 权限。

优先在插件和 Docker 网页检查，不重复安装容器。

十三、Cloudflare Tunnel：安装、Token、域名与保护

13.1 准备

准备 Cloudflare 账号、已接入其 DNS 的域名，以及本地可访问的服务。本文以 192.168.10.3:4533 为例，example.com 换成自己的域名。

先在本地浏览器打开 http://192.168.10.3:4533；源站正常后再配置 Tunnel。

13.2 安装插件

在 iStore 安装支持远程管理 Token 的 Cloudflare Tunnel/cloudflared 插件，刷新后进入配置页；商店未装则先完成第十一部分。

插件字段按实际版本，不把 DDNS 插件当作 Tunnel。

13.3 云端创建隧道并取得 Token

登录 Cloudflare One/Zero Trust。
进入 Networks → Connectors → Cloudflare Tunnels（部分界面称 Tunnels）。
创建 cloudflared 隧道，填写名称，例如 r4s-home。
在连接器安装说明中复制完整 Token；插件 Token 输入框只填令牌，不粘贴整条 Linux 安装命令。
回到 R4S 插件，选择 Token/远程管理模式，粘贴 Token，开启服务和开机启动，保存应用。
云端确认连接器 Healthy 后再发布服务。

Token 模式不上传 cert.pem，也不执行 Linux systemd 安装命令；cert.pem 属于另一种本地管理方式。官方流程

13.4 先给私人服务配置 Access

如果发布私人管理页，在 Zero Trust → Access → Applications：

添加 Self-hosted 应用。
应用域名填写即将发布的 music.example.com。
添加 Allow 策略，只允许指定邮箱/身份组；按需配置登录身份提供商或邮箱验证码。
保存，不能使用允许所有人的 Bypass 代替账号保护。

音乐客户端可能不兼容 Access 网页登录，个人使用优先走 Tailscale，不为兼容客户端取消全部保护。

13.5 添加域名和源站

回到 Tunnel，添加 Published application route/Public Hostname：

项目	示例
子域名	music
域名	example.com，换成自己的域名
Path	不需要路径限制时留空
服务类型	HTTP
服务地址	192.168.10.3:4533

保存后检查 DNS 路由。同名记录已存在时先确认用途，再调整冲突。

宿主机运行的 cloudflared 可用 127.0.0.1:4533；Docker bridge 中的 127.0.0.1 是容器自己。本文直接用 LAN 地址。

13.6 外网验证和故障检查

手机使用流量，打开 https://music.example.com。
先验证 Access 按指定身份登录，再验证应用账号登录和功能。
Q3000 不需要为 Tunnel 映射 80/443。
Token 不放到文章、截图和公开配置；不将路由器后台、Docker API 或 Samba 作为无认证公网服务发布。

故障先看插件日志；没有入口时在“状态 → 系统日志”搜索 cloudflared，再用本地浏览器检查源站。

Healthy 仅代表连上 Cloudflare。502 查源站地址/端口，认证失败查 Access 和应用账号，不通过关闭防火墙或跳过 TLS 校验解决。最后重启检查自动上线。

十四、验收与配置生效

检查	预期
R4S 默认路由	LAN → 192.168.10.1
Nikki	本机和家庭客户端均能正常使用
Tailscale	Running，本次地址正确
出口、子网	已通告并批准
手机流量	主路由、NAS、Docker 服务可访问
Nikki 入站	包含 tailscale 逻辑接口
Docker	独立挂载正确，允许 tailscale0，端口可达
Samba	指定用户可读写，无公网 445
Tunnel	在线、源站可达、访问保护正确

修改后保存并应用；需要刷新服务时在“系统 → 启动项”重启对应服务，通过本地地址操作。

若每次都要整机重启，保留日志排查。最后统一重启一次，验证路由、挂载、Nikki、Tailscale 和容器能自动恢复。

一、设备分工与接线 ​

二、离线定制固件 ​

三、Nikki：安装、导入 YAML、代理和 DNS ​

3.1 准备与检查 ​

3.2 安装 Nikki：预置版与原生版二选一 ​

3.3 上传并选择配置 ​

3.4 检查混入配置和控制面板 ​

3.5 设置代理和访问控制 ​

3.6 将家庭 DNS 交给 Nikki ​

3.7 启动、选节点、验证 ​

3.8 离线数据和后续更新 ​

四、配置旁路由和方案 B ​

4.1 R4S LAN ​

4.2 停用闲置 WAN ​

4.3 DNS 与主路由 ​

五、Tailscale：完整安装、登录、出口与子网配置 ​

5.1 准备：先确认 R4S 自己能联网 ​

5.2 检查安装；已预置则不重装 ​

5.3 首次启动与登录 ​

5.4 Community 设置逐项填写 ​

5.5 系统转发：正常已开启就不用修改 ​

5.6 创建 tailscale 接口和防火墙区域 ​

5.7 让远端流量进入 Nikki ​

5.8 Docker 服务访问：不要漏掉允许接口 ​

5.9 云端批准出口和家庭子网 ​

5.10 DNS 与手机配置 ​

5.11 保存、服务刷新与验收 ​

六、Tailscale、Nikki、Docker 三项关键配置 ​

6.1 Nikki 入站增加 Tailscale【远端流量使用 Nikki 必做】 ​

6.2 防火墙转发【本文旁路由方案必做】 ​

6.3 Docker 允许 tailscale0【远程访问 bridge 容器必做】 ​

七、手机使用、DNS 和可选优化 ​

7.1 手机连接 ​

7.2 DNS：不把覆盖当成必做 ​

7.3 Tailscale-MASQ【可选】 ​

7.4 UDP 41641 映射【可选】 ​

7.5 直连与 MTU ​

八、家里、公司、手机互通：公司主路由不能设置时怎么办 ​

8.1 先分清“哪些设备能互通” ​

8.2 两台 Tailscale 路由器的共同设置 ​

8.3 手机访问两地：公司主路由不用加静态路由 ​

8.4 两地普通设备主动互访：给参与设备一条正确路径 ​

8.5 何时才禁用 SNAT ​

8.6 验收方向 ​

九、Docker：分区、防爆锁、挂载与安装 ​

9.1 安装 DiskMan 并创建 Docker 分区 ​

9.2 核心：chattr +i 系统盘防爆锁 ​

9.3 按 UUID 精准挂载 ​

9.4 重启后验证挂载 ​

9.5 用原安装命令安装 Docker ​

9.6 打通访问接口与防火墙 ​

9.7 容器安装后的检查 ​

十、Samba 文件共享 ​

10.1 安装 Samba ​

10.2 SSH 创建用户 ​

10.3 创建剩余磁盘空间并挂载 ​

10.4 网页设置共享目录 ​

10.5 权限修正【重点】 ​

10.6 Windows 连接与验证 ​

十一、iStore 与首页：完整安装 ​

11.1 准备 ​

11.2 安装商店 ​

11.3 安装首页和中文包 ​

11.4 网页设置与验证 ​

十二、Navidrome：iStore 安装与音乐配置 ​

12.1 一键安装 ​

12.2 设置音乐和数据目录 ​

12.3 导入音乐和权限核对 ​

12.4 首次登录与扫描 ​

12.5 Tailscale 访问 ​

12.6 常见问题检查顺序 ​

十三、Cloudflare Tunnel：安装、Token、域名与保护 ​

13.1 准备 ​

13.2 安装插件 ​

13.3 云端创建隧道并取得 Token ​

13.4 先给私人服务配置 Access ​

13.5 添加域名和源站 ​

13.6 外网验证和故障检查 ​

十四、验收与配置生效 ​

一、设备分工与接线

二、离线定制固件

三、Nikki：安装、导入 YAML、代理和 DNS

3.1 准备与检查

3.2 安装 Nikki：预置版与原生版二选一

3.3 上传并选择配置

3.4 检查混入配置和控制面板

3.5 设置代理和访问控制

3.6 将家庭 DNS 交给 Nikki

3.7 启动、选节点、验证

3.8 离线数据和后续更新

四、配置旁路由和方案 B

4.1 R4S LAN

4.2 停用闲置 WAN

4.3 DNS 与主路由

五、Tailscale：完整安装、登录、出口与子网配置

5.1 准备：先确认 R4S 自己能联网

5.2 检查安装；已预置则不重装

5.3 首次启动与登录

5.4 Community 设置逐项填写

5.5 系统转发：正常已开启就不用修改

5.6 创建 tailscale 接口和防火墙区域

5.7 让远端流量进入 Nikki

5.8 Docker 服务访问：不要漏掉允许接口

5.9 云端批准出口和家庭子网

5.10 DNS 与手机配置

5.11 保存、服务刷新与验收

六、Tailscale、Nikki、Docker 三项关键配置

6.1 Nikki 入站增加 Tailscale【远端流量使用 Nikki 必做】

6.2 防火墙转发【本文旁路由方案必做】

6.3 Docker 允许 tailscale0【远程访问 bridge 容器必做】

七、手机使用、DNS 和可选优化

7.1 手机连接

7.2 DNS：不把覆盖当成必做

7.3 Tailscale-MASQ【可选】

7.4 UDP 41641 映射【可选】

7.5 直连与 MTU

八、家里、公司、手机互通：公司主路由不能设置时怎么办

8.1 先分清“哪些设备能互通”

8.2 两台 Tailscale 路由器的共同设置

8.3 手机访问两地：公司主路由不用加静态路由

8.4 两地普通设备主动互访：给参与设备一条正确路径

8.5 何时才禁用 SNAT

8.6 验收方向

九、Docker：分区、防爆锁、挂载与安装

9.1 安装 DiskMan 并创建 Docker 分区

9.2 核心：chattr +i 系统盘防爆锁

9.3 按 UUID 精准挂载

9.4 重启后验证挂载

9.5 用原安装命令安装 Docker

9.6 打通访问接口与防火墙

9.7 容器安装后的检查

十、Samba 文件共享

10.1 安装 Samba

10.2 SSH 创建用户

10.3 创建剩余磁盘空间并挂载

10.4 网页设置共享目录

10.5 权限修正【重点】

10.6 Windows 连接与验证

十一、iStore 与首页：完整安装

11.1 准备

11.2 安装商店

11.3 安装首页和中文包

11.4 网页设置与验证

十二、Navidrome：iStore 安装与音乐配置

12.1 一键安装

12.2 设置音乐和数据目录

12.3 导入音乐和权限核对

12.4 首次登录与扫描

12.5 Tailscale 访问

12.6 常见问题检查顺序

十三、Cloudflare Tunnel：安装、Token、域名与保护

13.1 准备

13.2 安装插件

13.3 云端创建隧道并取得 Token

13.4 先给私人服务配置 Access

13.5 添加域名和源站

13.6 外网验证和故障检查

十四、验收与配置生效