Ray's Blog

绿联云NAS Docker透明代理完全指南

Sun, 22 Feb 2026 00:51:43 +0800

绿联云 NAS Docker 透明代理完全指南：从入门到精通

设备环境：绿联云 DH4300PLUS（ARM64）· UGOS Pro（Debian 定制）· Docker · v2rayA 2.2.7.5 + Xray 26.1.23

目标：在绿联云 NAS 上部署 v2rayA 透明代理，实现局域网设备（手机、电脑、游戏主机等）仅修改网关即可科学上网，同时支持 IPv6 双栈和安全加固。

本文是四次深度排障实战的完整记录，涵盖 Docker 网络模式选型、macvlan 网络配置、IPv6 SLAAC 获取、透明代理模式选择、DNS 防污染、安全加固等全部核心话题。

背景与目标
踩坑之路：从 bridge 到绿联云面板 macvlan 再到命令行 macvlan
正确创建 Macvlan 网络（命令行方式）
v2rayA 容器部署与 IPv4 验证
IPv6 双栈配置：ULA + SLAAC 方案
透明代理模式选择：tproxy / redirect / TUN
v2rayA 面板配置详解
安全加固：封锁公网 IPv6 暴露
Macvlan 宿主机通信：vlink 桥接
其他容器走代理（青龙面板等）
持久化与开机自启
完整命令参考与 docker-compose
常见问题与排障速查

1. 背景与目标

家庭网络中，想让所有设备（手机、平板、电视、游戏主机）无感科学上网，最优雅的方案是旁路由 / 透明网关：

路由器负责基本的 DHCP 和 WiFi；
NAS 运行代理容器，作为局域网设备的网关；
设备只需把网关指向 NAS 的 IP，即可自动走代理。

绿联云 NAS（UGOS Pro）底层基于 Debian，原生支持 Docker，硬件性能足以胜任透明代理的加解密负载。但由于 UGOS 在内核、Docker 配置、网络架构上做了大量定制，实际部署中会遇到诸多”绿联专属”的坑。本文将逐一记录并给出解决方案。

2. 踩坑之路：从 bridge 到绿联云面板 macvlan 再到命令行 macvlan

本节记录真实的实验路径。如果你只想看结论，可以直接跳到第 3 节。

2.1 第一步：bridge / host 模式——此路不通

最初的想法很简单：用 Docker 默认的 bridge 网络或 host 模式跑 v2rayA。结果两条路都走不通：

模式	尝试结果
bridge（默认）	容器 IP 在 docker0 虚拟网段内，局域网设备无法直接访问容器 IP，无法用作网关
host	v2rayA 启动透明代理时会执行 `sysctl -w net.ipv4.ip_forward=0`，直接关闭宿主机 IP 转发，导致 NAS 上所有 bridge 容器（qBittorrent、Jellyfin 等）瞬间断网

结论：透明代理需要容器拥有独立的局域网 IP，只能用 macvlan 模式。

2.2 第二步：用绿联云可视化面板创建 macvlan——掉入深坑

知道要用 macvlan 后，自然的想法是通过绿联云的 Docker 可视化管理界面来创建。然而面板在引导创建 Macvlan 时，会强制要求先创建一个虚拟网桥来桥接物理网卡、系统虚拟网卡和 Macvlan 网络。

创建后发现透明代理完全不工作——流量转发全部被拦截。尝试了大量排查：

检查 iptables 规则，发现 FORWARD 链默认 DROP；
手动 iptables -F 清空规则后暂时能通，但 NAS 其他 Docker 服务又全挂了；
怀疑是 v2rayA 配置问题，反复调整代理模式、DNS 设置，均无效。

经过反复排查，最终定位到根因：

绿联云 UGOS 系统会将物理网卡 eth0 包裹在一个虚拟网桥 bridge0 中。UI 创建的 macvlan 实际上挂载在 bridge0 上而非 eth0 上，导致所有 macvlan 流量经过 bridge0 时被 bridge-nf-call-iptables 强制送入宿主机 iptables 链，被 Docker 的默认 FORWARD DROP 策略拦截。

eth0 → bridge0 (虚拟网桥) → 宿主机 IP
                  ↑
         macvlan 挂在这里 → 流量被 bridge-nf-call-iptables 拦截！

# ❌ UI 创建的 macvlan 等效于
docker network create -d macvlan -o parent=bridge0 ...

2.3 第三步：弃用面板，命令行直接绑定 eth0——跑通 IPv4

明白了根因后，操作分两步：

先在绿联云的 Docker 可视化面板中删除之前创建的 Macvlan 网络，然后进入 系统设置 → 网络 中删除 UI 自动创建的虚拟网桥（这一步是关键——删除网桥后 eth0 才会从 bridge0 中释放出来）；
通过 SSH 命令行直接绑定物理网卡 eth0 重新创建 macvlan：

# ✅ 正确做法：命令行创建，直接绑定 eth0
docker network create -d macvlan \
  --subnet=192.168.31.0/24 \
  --gateway=192.168.31.1 \
  -o parent=eth0 \
  macvlan_v2raya

启动 v2rayA 容器，手机设置网关为容器 IP，IPv4 透明代理一次跑通。

2.4 第四步：进一步跑通 IPv6 双栈

IPv4 成功后，继续攻克 IPv6（详见第 5 节）。

2.5 macvlan 的核心优势

回顾整个过程，macvlan 模式（正确绑定到 eth0）的核心优势：

容器拥有独立的局域网 IP（如 192.168.31.2），手机可以直接把网关指向它；
容器拥有独立的网络命名空间，iptables 规则只作用于容器内部，不影响宿主机和其他容器；
直接绑定物理网卡时，完全绕过 bridge-nf-call-iptables 等内核参数干扰。

3. 正确创建 Macvlan 网络（命令行方式）

3.1 创建命令

# ✅ 直接绑定物理网卡 eth0
docker network create -d macvlan \
  --subnet=192.168.31.0/24 \
  --gateway=192.168.31.1 \
  -o parent=eth0 \
  macvlan_v2raya

3.2 释放 eth0：删除绿联云的虚拟网桥

绿联云系统默认将 eth0 包裹在虚拟网桥 bridge0 中。如果 eth0 仍被 bridge0 占用（brctl show bridge0 可查看），macvlan 将无法直接绑定 eth0。需要先释放：

方法一（推荐）：通过绿联云系统 UI 删除

进入绿联云管理界面 → 系统设置 → 网络，找到之前创建的虚拟网桥并删除。删除后系统会自动将网络切换回物理网卡 eth0 直连，无需手动配置 IP 和路由。

注意：删除网桥的瞬间 NAS 管理连接会短暂中断，刷新页面即可恢复。

方法二（备选）：通过命令行手动拆除

如果 UI 中找不到删除选项，可以通过 SSH 手动操作：

# 查看 bridge0 是否包含 eth0
brctl show bridge0

# 如果包含，将 eth0 从 bridge0 中移除
ip link set bridge0 down
brctl delif bridge0 eth0
ip link del bridge0

# 将 IP 迁移到 eth0
ip addr add 192.168.31.178/24 dev eth0
ip link set eth0 up
ip route add default via 192.168.31.1

⚠️ 风险提示：命令行操作时 NAS 的管理 IP 会暂时中断，建议通过物理连接或 SSH 多开一个会话操作。此方式未经本文作者实测，仅作为理论参考。

3.3 替代方案：关闭 bridge-nf-call-iptables

⚠️ 未实测：本文作者未实际尝试此方案，仅作为理论备选。

如果不想拆 bridge0，可以关闭内核参数：

sysctl -w net.bridge.bridge-nf-call-iptables=0
sysctl -w net.bridge.bridge-nf-call-ip6tables=0

这样 bridge 上的流量不再被送入 iptables，但可能影响 Docker 的其他网络隔离功能。

4. v2rayA 容器部署与 IPv4 验证

命令行创建 macvlan 后（第 2.3 步），下一步就是启动 v2rayA 容器，验证 IPv4 透明代理是否跑通。如果你计划直接部署 IPv6 双栈版本，可以跳到第 5 节和第 12 节的终极命令。

4.1 启动容器

假设已按第 3 节创建好 macvlan 网络：

docker run -d \
  --name v2raya \
  --restart=always \
  --privileged \
  --network=macvlan_v2raya \
  --ip=192.168.31.2 \
  --sysctl net.ipv4.ip_forward=1 \
  -v /volume1/docker/v2raya/etc:/etc/v2raya \
  mzz2017/v2raya

关键参数说明：

参数	作用
`--privileged`	授予完整内核权限，透明代理需要操作 iptables/路由表
`--network=macvlan_v2raya`	使用 macvlan 网络
`--ip=192.168.31.2`	指定固定 IP，作为局域网网关地址
`--sysctl net.ipv4.ip_forward=1`	容器内启用 IP 转发
`-v ...:/etc/v2raya`	持久化配置文件

4.2 访问 Web 面板

浏览器打开 http://192.168.31.2:2017，首次访问需设置管理员密码。

4.3 客户端配置

手机/电脑的 WiFi 设置：

IP：手动或自动（保持局域网段即可）
网关：192.168.31.2（v2rayA 容器 IP）
DNS：192.168.31.2 或保持默认均可（v2rayA 会劫持 DNS 流量）

5. IPv6 双栈配置：ULA + SLAAC 方案

IPv4 透明代理跑通后（第 2.3 步），下一个目标就是让 IPv6 也走代理。这对应踩坑之路的第四步，也是整个部署中最”反直觉”的环节——Docker 对 IPv6 的支持远不如 IPv4 开箱即用，需要一套”ULA 激活 + SLAAC 获取”的组合拳。

5.1 问题背景

家用宽带的 IPv6 前缀（如 2408:xxxx:xxxx:xxxx::/64）是动态的，每隔 48-72 小时或重启路由器后会变化。如果在 macvlan 网络中写死公网 IPv6 前缀，前缀变化后容器 IPv6 立刻失效。

5.2 解决方案：ULA 激活 + SLAAC 获取公网地址

核心思路：

使用 ULA 地址（fd00:8::/64） 作为 macvlan 的 IPv6 子网，仅用于激活 Docker 的 IPv6 协议栈；
通过 SLAAC（accept_ra=2） 让容器自动从路由器获取公网 IPv6 地址；
删除 Docker 自动生成的 ULA 默认路由，避免路由冲突。

5.3 创建双栈 macvlan 网络

docker network create -d macvlan \
  --subnet=192.168.31.0/24 \
  --gateway=192.168.31.1 \
  --ipv6 \
  --subnet=fd00:8::/64 \
  --gateway=fd00:8::1 \
  -o parent=eth0 \
  macvlan_v2raya

关键发现：Docker 默认不为 macvlan 接口启用 IPv6。必须在 docker network create 时加上 --ipv6 参数，否则容器网卡的 IPv6 协议栈不会被激活，无法接收 RA（Router Advertisement）。

5.4 `daemon.json` 配置（可选）

对于 macvlan 模式，通常不需要修改 daemon.json。以下配置仅在使用 bridge 网络的 IPv6 时需要：

{
    "data-root": "/volume1/@docker",
    "ipv6": true,
    "fixed-cidr-v6": "fd00:1::/64",
    "experimental": true,
    "ip6tables": true
}

5.5 启动带 IPv6 支持的容器

docker run -d \
  --name v2raya \
  --restart=always \
  --privileged \
  --network=macvlan_v2raya \
  --ip=192.168.31.2 \
  --sysctl net.ipv4.ip_forward=1 \
  --sysctl net.ipv6.conf.all.forwarding=1 \
  --sysctl net.ipv6.conf.all.accept_ra=2 \
  --sysctl net.ipv6.conf.default.accept_ra=2 \
  --sysctl net.ipv6.conf.eth0.accept_ra=2 \
  -v /volume1/docker/v2raya/etc:/etc/v2raya \
  --entrypoint sh \
  mzz2017/v2raya \
  -c "echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind; ip -6 route del default via fd00:8::1 2>/dev/null || true; ip6tables -I INPUT -p tcp --dport 2017 -j DROP; exec v2raya"

关键 sysctl 参数解析

参数	作用
`net.ipv6.conf.all.forwarding=1`	启用 IPv6 转发（旁路由必需）
`net.ipv6.conf.all.accept_ra=2`	值为 `2` 表示即使在 forwarding 开启时也接受 RA
`net.ipv6.conf.eth0.accept_ra=2`	对容器内 eth0 接口单独设置

为什么 accept_ra 必须是 2？ Linux 内核的默认行为是：当 forwarding=1 时自动忽略 RA（因为转发节点不应该动态获取地址）。设为 2 可以强制覆盖这一行为。

entrypoint 启动脚本解析

# 1. 开启 ip_nonlocal_bind（tproxy 透明代理必需，否则 connect: invalid argument）
echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind

# 2. 删除 Docker 自动创建的 ULA 默认路由（避免 IPv6 流量走 fd00:8::1 黑洞）
ip -6 route del default via fd00:8::1 2>/dev/null || true

# 3. 在 IPv6 防火墙中拦截对 2017 端口的入站连接（安全加固，详见第 8 节）
ip6tables -I INPUT -p tcp --dport 2017 -j DROP

# 4. 启动 v2rayA 主进程
exec v2raya

5.6 验证 IPv6

# 进入容器
docker exec -it v2raya sh

# 查看网卡地址，应看到 2408 开头的公网 IPv6
ip -6 addr show eth0

# 测试 IPv6 连通性
ping6 ipv6.google.com

成功获取公网 IPv6 地址示例：

inet6 2408:xxxx:xxxx:xxxx:42:acff:fe12:3456/64 scope global dynamic
inet6 fd00:8::2/64 scope global        ← ULA 地址（仅用于激活协议栈）
inet6 fe80::42:c0ff:fea8:1f02/64 scope link  ← 链路本地地址

6. 透明代理模式选择：tproxy / redirect / TUN

IPv4 和 IPv6 网络层面都跑通后，接下来需要选择和调优透明代理的工作模式。看似只是 v2rayA 面板上选一个选项的事，实际上又踩了不少坑——tproxy 模式一度因为 connect: invalid argument 和 DNS 死锁被误判为”在 macvlan 上不可用”，最终经过深度排查才定位到 ip_nonlocal_bind 这个隐藏的内核参数。

6.1 三种模式对比

模式	工作层级	TCP	UDP	性能	macvlan 兼容性
redirect	iptables NAT 表	✅	❌	高	✅ 好
tproxy	iptables mangle 表	✅	✅	最高	✅ 需正确配置
system tun	虚拟 TUN 网卡	✅	✅	中高	✅ 好
gvisor tun	用户态 TUN 模拟	✅	✅	中	✅ 最好

6.2 tproxy 在 macvlan 中的排障实录

在最初的测试中，tproxy 模式在 macvlan 容器内会遇到 connect: invalid argument 错误。经过多轮深度排查，最终定位到两个根因，并全部解决：

根因一：ip_nonlocal_bind 未开启（关键！）

tproxy 需要绑定非本机 IP（冒充被劫持流量的目标地址）。绿联云系统的 net.ipv4.ip_nonlocal_bind 默认为 0，这直接导致了 connect: invalid argument 错误。修复方法：

# 在容器内开启（必须在 v2rayA 启动前执行）
echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind
# 或
sysctl -w net.ipv4.ip_nonlocal_bind=1

这是整个 tproxy 问题的核心根因，并非 macvlan 与 tproxy 不兼容，而是缺少这个内核参数。

根因二：DNS 自拦截死锁

macvlan 容器拥有独立的网络命名空间，tproxy 的 iptables 规则会劫持容器自身发出的 DNS 请求，形成死循环：

v2rayA 需要解析代理节点域名 → DNS 请求被自己的 tproxy 规则拦截 → 再次交给 v2rayA 处理 → 无限循环

解决方案：

代理节点配置使用 IP 地址而非域名；
DNS 服务器使用直连 IP（如 223.5.5.5、8.8.8.8），避免经过域名二次解析；
v2rayA 中将”防止 DNS 污染”设为关闭或 DoH（DoH 更安全但首屏可能稍慢）；
DNS 设置中排除代理节点域名的解析。

内核兼容性验证

通过 ping -m 255 和 ip rule add fwmark 测试，确认绿联云内核完整支持 SO_MARK 和策略路由（CONFIG_IP_MULTIPLE_TABLES=y）。实际验证中，tproxy 所需的 xt_TPROXY 模块、table 100 策略路由、fwmark 0x40/0xc0 标记规则均正常工作，iptables 链（TP_PRE、TP_OUT、TP_RULE、TP_MARK）的包计数器持续增长，日志中出现 [transparent -> proxy] 记录，证明 tproxy 在 macvlan 环境中完全可用。

6.3 最终推荐：tproxy 模式

经过完整排障，tproxy 在 macvlan 环境中完全可用，并且是性能最优的选择：

完美支持 TCP + UDP（游戏主机联机无忧）；
内核级透明代理，性能最高，CPU 开销最低；
相比 TUN 模式少约 10-20% 的 CPU 使用率（TUN 需要用户态 ↔ 内核态数据拷贝）；
IPv4 和 IPv6 双栈 tproxy 均可正常工作。

tproxy 的前置条件（缺一不可）：

# 1. 开启 ip_nonlocal_bind（核心！否则 connect: invalid argument）
sysctl -w net.ipv4.ip_nonlocal_bind=1

# 2. 开启 IP 转发
sysctl -w net.ipv4.ip_forward=1

# 3. 确保容器以 --privileged 运行（需要操作 iptables mangle 表和策略路由）

备选方案：如果因任何原因无法使用 tproxy（如内核缺少 xt_TPROXY 模块），可退而求其次选择 system tun 或 gvisor tun 模式，兼容性好但性能略低。

7. v2rayA 面板配置详解

7.1 核心设置

在 v2rayA 的 设置 (Settings) 页面：

设置项	推荐值	说明
透明代理/系统代理实现方式	tproxy	性能最优；如不可用改 system tun
透明代理/系统代理	启用：大陆白名单模式	国内直连，其余走代理
防止 DNS 污染	关闭或 DoH	关闭最稳；DoH 更安全但首屏可能稍慢
特殊模式	关闭	非软路由环境无需开启
TCPFastOpen	关闭或保持默认	部分线路不支持会导致连接失败
多路复用（Mux）	关闭	开启会增加延迟，仅在线路极差时考虑
流量嗅探	启用	关键！用于纠偏被污染的 DNS 结果

7.2 流量嗅探（Sniffing）的重要性

嗅探功能是 v2rayA 透明代理的”灵魂”：

手机向路由器发起 DNS 请求，可能拿到被污染的错误 IP；
手机向错误 IP 发起连接，流量经过 v2rayA；
v2rayA 嗅探 TLS ClientHello 中的 SNI（域名信息），发现实际要访问 youtube.com；
v2rayA 丢弃错误 IP，在远端重新解析正确地址并建立连接。

必须开启 QUIC 嗅探：YouTube App 大量使用 QUIC（UDP 443）协议。如果不开启 QUIC 嗅探，App 可能无限转圈。

7.3 白名单模式注意事项

“大陆白名单”模式会在 iptables 中注入数千条中国 IP 段的 RETURN 规则。在 ARM 架构的 NAS 上，这可能导致：

规则注入时间极长（数十秒甚至数分钟）；
每个数据包都要遍历所有规则，造成显著的 CPU 负载和延迟。

如果遇到性能问题，建议改用 GFWList 模式（仅代理被墙域名），规则数量大幅减少，性能压力显著降低。（⚠️ 本文作者使用的是白名单模式，GFWList 模式未实测。）

8. 安全加固：封锁公网 IPv6 暴露

IPv6 双栈跑通、tproxy 模式调通之后，本以为大功告成。然而在一次偶然的测试中，用手机 5G 流量直接访问容器的公网 IPv6 地址，竟然打开了 v2rayA 管理面板——这意味着任何人都可以从公网控制你的代理服务。

8.1 问题发现

配置 IPv6 双栈后，v2rayA 容器获得了公网 IPv6 地址（如 2408:xxxx:xxxx:xxxx:42:acff:fe12:3456）。由于 v2rayA 默认监听所有网络接口，Web 管理面板直接暴露在公网：

手机 5G 流量访问 http://[2408:...]:2017 → 直接打开管理面板！

8.2 尝试过的方案

方案	结果
设置环境变量 `V2RAYA_ADDRESS=0.0.0.0:2017`	❌ 无效，v2rayA 仍监听所有地址
启动参数 `--address 0.0.0.0:2017`	❌ 无效，Go 程序仍遍历所有 IP 并监听

v2rayA 基于 Go 语言开发，其监听逻辑会遍历所有网络接口并绑定。日志中打印的地址列表实际反映了真实的监听状态。

8.3 终极解决方案：ip6tables 内核级封锁

既然应用层无法控制，直接在容器内的 IPv6 防火墙拦截：

ip6tables -I INPUT -p tcp --dport 2017 -j DROP

将这条命令写入容器的 entrypoint 脚本，在 v2rayA 启动之前执行：

--entrypoint sh mzz2017/v2raya \
-c "echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind; \
    ip -6 route del default via fd00:8::1 2>/dev/null || true; \
    ip6tables -I INPUT -p tcp --dport 2017 -j DROP; \
    exec v2raya"

8.4 为什么这样做是安全的？

只拦截 INPUT 入站：不影响容器通过 IPv6 出站连接代理节点；
内核级拦截：数据包在到达 v2rayA 进程之前就被丢弃，效率极高；
随容器自动生效：写在 entrypoint 中，容器重启后自动恢复。

8.5 验证

# 局域网 IPv4 访问（应成功）
curl http://192.168.31.2:2017

# 公网 IPv6 访问（应超时）
# 手机关闭 WiFi，使用 5G 流量
# 浏览器访问 http://[2408:xxxx:xxxx:xxxx:...]:2017
# 预期：连接超时

9. Macvlan 宿主机通信：vlink 桥接

⚠️ 未实测：本节内容为理论方案，作者尚未在自己的环境中实际配置 vlink。

代理功能完善、安全加固完成后，日常使用中又发现了一个问题：从 NAS 本机竟然访问不了 v2rayA 的 Web 面板，NAS 上的其他容器也无法通过 v2rayA 上网。这是 macvlan 的一个”设计特性”——宿主机与自己创建的 macvlan 容器天然隔离。

9.1 问题

Macvlan 有一个设计层面的限制：宿主机与其自身创建的 macvlan 容器无法直接通信。这意味着：

NAS 本机无法访问 192.168.31.2:2017（v2rayA 面板）；
NAS 本机的应用（如青龙面板的脚本）无法通过 v2rayA 代理上网。

9.2 解决方案：创建 vlink 子接口

# 创建 macvlan 子接口
ip link add vlink link eth0 type macvlan mode bridge

# 分配一个局域网 IP（不要与其他设备冲突）
ip addr add 192.168.31.100/32 dev vlink

# 启用接口
ip link set vlink up

# 添加到 v2rayA 容器的路由
ip route add 192.168.31.2/32 dev vlink

现在宿主机可以通过 vlink 接口与 macvlan 容器通信了。

9.3 如果需要 NAS 本机也走代理

⚠️ 未实测 + 高风险：此操作未经作者实测，且风险较高，请谨慎操作。

# 将 vlink 设为默认网关（宿主机流量走 v2rayA）
ip route del default
ip route add default via 192.168.31.2 dev vlink

⚠️ 风险提示：如果 v2rayA 容器停止，宿主机将完全断网。建议仅在测试时使用，生产环境建议为 NAS 本机保留直连路由。

10. 其他容器走代理（青龙面板等）

⚠️ 未实测：本节两种方案均为理论指导，作者尚未实际将青龙等容器接入代理。

10.1 方案一：加入 macvlan 网络

将需要走代理的容器也加入同一个 macvlan 网络，并将网关指向 v2rayA：

docker run -d \
  --name qinglong \
  --network=macvlan_v2raya \
  --ip=192.168.31.3 \
  whyour/qinglong

容器内手动设置路由：

docker exec qinglong ip route replace default via 192.168.31.2

10.2 方案二：使用 HTTP 代理环境变量

如果不想改网络模式，可以在容器启动时注入代理环境变量：

docker run -d \
  --name qinglong \
  -e HTTP_PROXY=http://192.168.31.2:20171 \
  -e HTTPS_PROXY=http://192.168.31.2:20171 \
  -e ALL_PROXY=socks5://192.168.31.2:20170 \
  whyour/qinglong

注意：需要在 v2rayA 设置中确认 SOCKS5（20170）和 HTTP（20171）代理端口已开启。

11. 持久化与开机自启

11.1 Docker 自动重启

容器使用 --restart=always 参数，Docker 服务启动时会自动拉起容器。macvlan 网络和容器配置均持久化存储，重启 NAS 后自动恢复。

11.2 vlink 和内核参数的持久化

⚠️ 未实测：以下启动脚本为理论方案，作者尚未在绿联云上实际配置开机自启脚本。

Docker 容器内的 entrypoint 脚本（ip6tables 规则、路由删除）会随容器启动自动执行。但宿主机上的 vlink 和内核参数需要通过启动脚本持久化：

# /etc/rc.local 或绿联云的自启动脚本
#!/bin/bash

# 如果通过绿联云系统设置删除了虚拟网桥，系统会自动切回 eth0 直连，通常无需额外配置
# 如果是命令行手动拆除 bridge0，则需要手动恢复 eth0 的 IP：
# ip addr add 192.168.31.178/24 dev eth0
# ip route add default via 192.168.31.1

# 创建 vlink（如需宿主机访问 v2rayA）
ip link add vlink link eth0 type macvlan mode bridge
ip addr add 192.168.31.100/32 dev vlink
ip link set vlink up
ip route add 192.168.31.2/32 dev vlink

# 确保宿主机 ip_forward 开启（bridge 容器依赖）
sysctl -w net.ipv4.ip_forward=1
# 注意：ip_nonlocal_bind 无需在宿主机设置，已在容器 entrypoint 中配置（容器有独立的网络命名空间）

注意：绿联云系统升级可能覆盖自定义启动脚本。建议升级前备份。

12. 完整命令参考与 docker-compose

12.1 完整 Docker 命令（终极版）

# 1. 创建双栈 macvlan 网络
docker network create -d macvlan \
  --subnet=192.168.31.0/24 \
  --gateway=192.168.31.1 \
  --ipv6 \
  --subnet=fd00:8::/64 \
  --gateway=fd00:8::1 \
  -o parent=eth0 \
  macvlan_v2raya

# 2. 启动 v2rayA 容器（IPv6 + 安全加固）
docker run -d \
  --name v2raya \
  --restart=always \
  --privileged \
  --network=macvlan_v2raya \
  --ip=192.168.31.2 \
  --sysctl net.ipv4.ip_forward=1 \
  --sysctl net.ipv6.conf.all.forwarding=1 \
  --sysctl net.ipv6.conf.all.accept_ra=2 \
  --sysctl net.ipv6.conf.default.accept_ra=2 \
  --sysctl net.ipv6.conf.eth0.accept_ra=2 \
  -v /volume1/docker/v2raya/etc:/etc/v2raya \
  --entrypoint sh \
  mzz2017/v2raya \
  -c "echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind; ip -6 route del default via fd00:8::1 2>/dev/null || true; ip6tables -I INPUT -p tcp --dport 2017 -j DROP; exec v2raya"

12.2 docker-compose.yml

⚠️ 未实测：以下 docker-compose 配置由 docker run 命令等价转换而来，作者实际使用的是 docker run 命令行方式。

version: "3.9"

services:
  v2raya:
    image: mzz2017/v2raya
    container_name: v2raya
    restart: always
    privileged: true
    networks:
      macvlan_v2raya:
        ipv4_address: 192.168.31.2
    sysctls:
      - net.ipv4.ip_forward=1
      - net.ipv6.conf.all.forwarding=1
      - net.ipv6.conf.all.accept_ra=2
      - net.ipv6.conf.default.accept_ra=2
      - net.ipv6.conf.eth0.accept_ra=2
    volumes:
      - /volume1/docker/v2raya/etc:/etc/v2raya
    entrypoint: sh
    command: >
      -c "echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind;
          ip -6 route del default via fd00:8::1 2>/dev/null || true;
          ip6tables -I INPUT -p tcp --dport 2017 -j DROP;
          exec v2raya"

networks:
  macvlan_v2raya:
    driver: macvlan
    driver_opts:
      parent: eth0
    enable_ipv6: true
    ipam:
      config:
        - subnet: 192.168.31.0/24
          gateway: 192.168.31.1
        - subnet: fd00:8::/64
          gateway: fd00:8::1

13. 常见问题与排障速查

Q1：v2rayA 启动后，NAS 上其他 Docker 容器全部断网

原因：v2rayA 以 host 模式运行，启动透明代理时关闭了 ip_forward。

解决：改用 macvlan 模式部署 v2rayA。

Q2：手机设置网关后能上百度，但不能上 Google

排查步骤：

检查手机是否关闭了 IPv6（IPv6 流量会绕过 IPv4 透明代理）；
检查 v2rayA 日志是否有 [transparent -> proxy] 记录；
检查代理节点是否正常连通。

Q3：手机设置网关后百度和 Google 都打不开

常见原因：

tproxy 模式下 ip_nonlocal_bind=0，导致直连流量报 invalid argument；
DNS 死锁：代理节点使用域名，DNS 请求被代理自身拦截形成环路。

解决：

确保 ip_nonlocal_bind=1（sysctl -w net.ipv4.ip_nonlocal_bind=1）；
将”防止 DNS 污染”设为关闭；
代理节点使用 IP 地址而非域名。

Q4：YouTube App 无限转圈，但浏览器正常

原因：YouTube App 使用 QUIC（UDP 443）协议，v2rayA 未嗅探 QUIC 流量。

解决：在 v2rayA 设置中开启 QUIC 嗅探。

Q5：`iptables -F` 能”修复”透明代理，但 NAS 其他服务挂了

原因：macvlan 绑定在 bridge0 上，bridge-nf-call-iptables=1 导致 bridge 流量被 iptables FORWARD DROP 规则拦截。iptables -F 清空了 DROP 规则所以暂时通了，但也清掉了 Docker 的其他必要规则。

解决：macvlan 绑定到 eth0 而非 bridge0（参见第 2.2 和第 3 节）。

Q6：容器获取不到公网 IPv6 地址

排查清单：

macvlan 创建时是否加了 --ipv6 参数；
容器启动时是否设置了 accept_ra=2；
是否删除了 ULA 默认路由（否则 SLAAC 的路由会被覆盖）；
路由器是否开启了 IPv6 RA 广播。

# 容器内检查
ip -6 addr show eth0      # 查看地址
ip -6 route show           # 查看路由表，default 应指向路由器

Q7：v2rayA 面板可以通过公网 IPv6 访问（安全隐患）

解决：在容器 entrypoint 中添加 ip6tables -I INPUT -p tcp --dport 2017 -j DROP。

Q8：DoH 开启后首屏加载变慢

原因：DoH 需要 TCP + TLS 握手，且请求还要经过代理隧道，首次解析延迟较高。后续请求受益于连接复用和 DNS 缓存，速度恢复正常。

优化方案：

使用 DNS 分流：国内域名走 UDP DNS（223.5.5.5），海外域名走 DoH；
如果手机同时开了代理软件（Fake-IP 模式），NAS 上可以关闭 DoH，因为 DNS 解析已被手机代理接管。

Q9：宿主机访问不了 v2rayA 面板

原因：macvlan 的设计限制——宿主机与自身的 macvlan 容器隔离。

解决：创建 vlink 子接口（参见第 9 节）。

Q10：NAS 重启后 IPv6 前缀变化，容器 IPv6 失效

解决：使用 ULA + SLAAC 方案（参见第 5 节）。macvlan 使用固定的 ULA 子网 fd00:8::/64，公网 IPv6 通过 SLAAC 动态获取，无需手动更新。

总结

本文完整记录了在绿联云 NAS 上从零搭建 Docker 透明代理的全过程，核心结论如下：

网络模式：必须使用 macvlan，避免 host 模式破坏其他容器；
macvlan 绑定：直接绑定到 eth0，避免 bridge0 带来的 iptables 干扰；
IPv6 方案：ULA 激活协议栈 + SLAAC 获取公网地址 + 删除 ULA 默认路由；
透明代理模式：推荐 tproxy 模式，性能最优；关键前置条件为 ip_nonlocal_bind=1、DNS 直连 IP、--privileged 权限；
安全加固：ip6tables 封锁公网 IPv6 入站，防止管理面板暴露；
DNS 策略：开启嗅探（含 QUIC），避免 DNS 死锁，按需开启 DoH/分流。

这套方案经过反复实测验证，可以稳定运行，实现全家设备仅改网关即可无感科学上网的终极目标。

隐私政策

Mon, 22 Sep 2025 13:21:05 +0800

隐私政策

更新日期：2025/9/22

生效日期：2025/9/22

导言

战争前线 是一款由 RayLab （以下简称“我们”）提供的产品。您在使用我们的服务时，我们可能会收集和使用您的相关信息。我们希望通过本《隐私政策》向您说明，在使用我们的服务时，我们如何收集、使用、储存和分享这些信息，以及我们为您提供的访问、更新、控制和保护这些信息的方式。本《隐私政策》与您所使用的 战争前线 服务息息相关，希望您仔细阅读，在需要时，按照本《隐私政策》的指引，作出您认为适当的选择。本《隐私政策》中涉及的相关技术词汇，我们尽量以简明扼要的表述，并提供进一步说明的链接，以便您的理解。

您使用或继续使用我们的服务，即意味着同意我们按照本《隐私政策》收集、使用、储存和分享您的相关信息。

如对本《隐私政策》或相关事宜有任何问题，请通过 1422401186@qq.com 与我们联系。

1. 我们收集的信息

我们或我们的第三方合作伙伴提供服务时，可能会收集、储存和使用下列与您有关的信息。如果您不提供相关信息，可能无法注册成为我们的用户或无法享受我们提供的某些服务，或者无法达到相关服务拟达到的效果。

2. 信息的存储

2.1 信息存储的方式和期限

我们会通过安全的方式存储您的信息，包括本地存储（例如利用APP进行数据缓存）、数据库和服务器日志。
一般情况下，我们只会在为实现服务目的所必需的时间内或法律法规规定的条件下存储您的个人信息。

2.2 信息存储的地域

我们会按照法律法规规定，将境内收集的用户个人信息存储于中国境内。
目前我们不会跨境传输或存储您的个人信息。将来如需跨境传输或存储的，我们会向您告知信息出境的目的、接收方、安全保证措施和安全风险，并征得您的同意。

2.3 产品或服务停止运营时的通知

当我们的产品或服务发生停止运营的情况时，我们将以推送通知、公告等形式通知您，并在合理期限内删除您的个人信息或进行匿名化处理，法律法规另有规定的除外。

3. 信息安全

我们使用各种安全技术和程序，以防信息的丢失、不当使用、未经授权阅览或披露。例如，在某些服务中，我们将利用加密技术（例如SSL）来保护您提供的个人信息。但请您理解，由于技术的限制以及可能存在的各种恶意手段，在互联网行业，即便竭尽所能加强安全措施，也不可能始终保证信息百分之百的安全。您需要了解，您接入我们的服务所用的系统和通讯网络，有可能因我们可控范围外的因素而出现问题。

4. 我们如何使用信息

我们可能将在向您提供服务的过程之中所收集的信息用作下列用途：

向您提供服务；
在我们提供服务时，用于身份验证、客户服务、安全防范、诈骗监测、存档和备份用途，确保我们向您提供的产品和服务的安全性；
帮助我们设计新服务，改善我们现有服务；
使我们更加了解您如何接入和使用我们的服务，从而针对性地回应您的个性化需求，例如语言设定、位置设定、个性化的帮助服务和指示，或对您和其他用户作出其他方面的回应；
向您提供与您更加相关的广告以替代普遍投放的广告；
评估我们服务中的广告和其他促销及推广活动的效果，并加以改善；
软件认证或管理软件升级；
让您参与有关我们产品和服务的调查。

5. 信息共享

目前，我们不会主动共享或转让您的个人信息至第三方，如存在其他共享或转让您的个人信息或您需要我们将您的个人信息共享或转让至第三方情形时，我们会直接或确认第三方征得您对上述行为的明示同意。

为了投放广告，评估、优化广告投放效果等目的，我们需要向广告主及其代理商等第三方合作伙伴共享您的部分数据，要求其严格遵守我们关于数据隐私保护的措施与要求，包括但不限于根据数据保护协议、承诺书及相关数据处理政策进行处理，避免识别出个人身份，保障隐私安全。

我们不会向合作伙伴分享可用于识别您个人身份的信息（例如您的姓名或电子邮件地址），除非您明确授权。

我们不会对外公开披露所收集的个人信息，如必须公开披露时，我们会向您告知此次公开披露的目的、披露信息的类型及可能涉及的敏感信息，并征得您的明示同意。

随着我们业务的持续发展，我们有可能进行合并、收购、资产转让等交易，我们将告知您相关情形，按照法律法规及不低于本《隐私政策》所要求的标准继续保护或要求新的控制者继续保护您的个人信息。

另外，根据相关法律法规及国家标准，以下情形中，我们可能会共享、转让、公开披露个人信息无需事先征得您的授权同意：

与国家安全、国防安全直接相关的；
与公共安全、公共卫生、重大公共利益直接相关的；
犯罪侦查、起诉、审判和判决执行等直接相关的；
出于维护个人信息主体或其他个人的生命、财产等重大合法权益但又很难得到本人同意的；
个人信息主体自行向社会公众公开个人信息的；
从合法公开披露的信息中收集个人信息的，如合法的新闻报道、政府信息公开等渠道。

6. 您的权利

在您使用我们的服务期间，我们可能会视产品具体情况为您提供相应的操作设置，以便您可以查询、删除、更正或撤回您的相关个人信息，您可参考相应的具体指引进行操作。此外，我们还设置了投诉举报渠道，您的意见将会得到及时的处理。如果您无法通过上述途径和方式行使您的个人信息主体权利，您可以通过本《隐私政策》中提供的联系方式提出您的请求，我们会按照法律法规的规定予以反馈。

7. 变更

我们可能适时修订本《隐私政策》的条款。当变更发生时，我们会在版本更新时向您提示新的《隐私政策》，并向您说明生效日期。请您仔细阅读变更后的《隐私政策》内容，若您继续使用我们的服务，即表示您同意我们按照更新后的《隐私政策》处理您的个人信息。

8. 未成年人保护

我们鼓励父母或监护人指导未满十八岁的未成年人使用我们的服务。我们建议未成年人鼓励他们的父母或监护人阅读本《隐私政策》，并建议未成年人在提交的个人信息之前寻求父母或监护人的同意和指导。

欢迎使用Z-BlogPHP！

Fri, 11 Jul 2025 10:08:28 +0800

欢迎使用Z-Blog，这是程序自动生成的文章，您可以删除或是编辑它:)

系统生成了一个留言本和一篇《欢迎使用Z-BlogPHP！》，祝您使用愉快！

Ray's Blog

绿联云NAS Docker透明代理完全指南

绿联云 NAS Docker 透明代理完全指南：从入门到精通

目录

1. 背景与目标

2. 踩坑之路：从 bridge 到绿联云面板 macvlan 再到命令行 macvlan

2.1 第一步：bridge / host 模式——此路不通

2.2 第二步：用绿联云可视化面板创建 macvlan——掉入深坑

2.3 第三步：弃用面板，命令行直接绑定 eth0——跑通 IPv4

2.4 第四步：进一步跑通 IPv6 双栈

2.5 macvlan 的核心优势

3. 正确创建 Macvlan 网络（命令行方式）

3.1 创建命令

3.2 释放 eth0：删除绿联云的虚拟网桥

3.3 替代方案：关闭 bridge-nf-call-iptables

4. v2rayA 容器部署与 IPv4 验证

4.1 启动容器

4.2 访问 Web 面板

4.3 客户端配置

5. IPv6 双栈配置：ULA + SLAAC 方案

5.1 问题背景

5.2 解决方案：ULA 激活 + SLAAC 获取公网地址

5.3 创建双栈 macvlan 网络

5.4 daemon.json 配置（可选）

5.5 启动带 IPv6 支持的容器

关键 sysctl 参数解析

entrypoint 启动脚本解析

5.6 验证 IPv6

6. 透明代理模式选择：tproxy / redirect / TUN

6.1 三种模式对比

6.2 tproxy 在 macvlan 中的排障实录

6.3 最终推荐：tproxy 模式

7. v2rayA 面板配置详解

7.1 核心设置

7.2 流量嗅探（Sniffing）的重要性

7.3 白名单模式注意事项

8. 安全加固：封锁公网 IPv6 暴露

8.1 问题发现

8.2 尝试过的方案

8.3 终极解决方案：ip6tables 内核级封锁

8.4 为什么这样做是安全的？

8.5 验证

9. Macvlan 宿主机通信：vlink 桥接

9.1 问题

9.2 解决方案：创建 vlink 子接口

9.3 如果需要 NAS 本机也走代理

10. 其他容器走代理（青龙面板等）

10.1 方案一：加入 macvlan 网络

10.2 方案二：使用 HTTP 代理环境变量

11. 持久化与开机自启

11.1 Docker 自动重启

11.2 vlink 和内核参数的持久化

12. 完整命令参考与 docker-compose

12.1 完整 Docker 命令（终极版）

12.2 docker-compose.yml

13. 常见问题与排障速查

Q1：v2rayA 启动后，NAS 上其他 Docker 容器全部断网

Q2：手机设置网关后能上百度，但不能上 Google

Q3：手机设置网关后百度和 Google 都打不开

Q4：YouTube App 无限转圈，但浏览器正常

Q5：iptables -F 能”修复”透明代理，但 NAS 其他服务挂了

Q6：容器获取不到公网 IPv6 地址

Q7：v2rayA 面板可以通过公网 IPv6 访问（安全隐患）

Q8：DoH 开启后首屏加载变慢

Q9：宿主机访问不了 v2rayA 面板

Q10：NAS 重启后 IPv6 前缀变化，容器 IPv6 失效

总结

隐私政策

隐私政策

导言

1. 我们收集的信息

2. 信息的存储

3. 信息安全

4. 我们如何使用信息

5. 信息共享

6. 您的权利

7. 变更

8. 未成年人保护

欢迎使用Z-BlogPHP！

5.4 `daemon.json` 配置（可选）

Q5：`iptables -F` 能”修复”透明代理，但 NAS 其他服务挂了