但是随着 NAS、服务器、智能家居、远程访问、IPv6、虚拟机和代理服务不断加入，
网络很快就会从一个简单设备，变成一个需要长期维护的小型系统。
我过去也尝试过把拨号、DHCP、DNS、防火墙、无线网络、代理插件和策略分流，
全部集中在一台 OpenWrt 路由器中。
这种方案刚开始确实很方便，但运行时间越长，问题也越明显：
- 代理插件升级失败，可能导致整个家庭网络断网。
- DNS 配置发生冲突，所有设备都可能无法解析域名。
- 代理核心崩溃以后，NAS、电视和智能家居也会受到影响。
- 排查故障时，很难判断问题发生在路由、DNS、代理还是远程服务器。
- 每次升级或修改配置，都担心影响正在使用网络的其他设备。
最终，我选择把整个网络拆成三个独立层级：
- MikroTik：负责主路由、DHCP、防火墙、NAT、IPv6 和基础网络。
- OpenWrt：负责代理、DNS 分流、透明接管和策略控制。
- Xray VPS：负责远程加密连接和海外互联网出口。
这套架构最重要的目标，不是让测速数字更高，而是让整个网络拥有清晰的边界、
独立的故障域和随时可以启用的回退路径。
一、整体网络架构
这套架构的核心，是让 MikroTik 保持纯粹，让 OpenWrt 专注代理，
让 Xray 只负责远程传输。
1.1 网络拓扑
Internet
│
运营商宽带 / 光猫
│
▼
MikroTik RouterOS 主路由
192.168.16.1
│
┌────────────────┼────────────────┐
│ │ │
▼ ▼ ▼
无线 AP NAS / PVE OpenWrt
192.168.16.5
│
┌────────────┴────────────┐
│ │
▼ ▼
国内流量 海外流量
DIRECT │
│ ▼
│ Xray / sing-box
│ │
│ ▼
│ 远程 VPS
│ │
└─────────────┬───────────┘
▼
Internet
1.2 设备职责
| 设备 | 主要职责 | 不负责的内容 |
|---|---|---|
| MikroTik | DHCP、防火墙、NAT、IPv6、主路由、WireGuard | 不运行代理插件 |
| OpenWrt | 透明代理、DNS 分流、节点选择、规则匹配 | 不负责全网 DHCP 和主路由拨号 |
| Xray VPS | 远程加密连接、海外出口 | 不参与家庭局域网管理 |
| 无线 AP | 提供 Wi-Fi 接入 | 不负责 NAT、DHCP 或代理 |
这样设计以后，即使 OpenWrt 或 Xray 节点出现故障，MikroTik 仍然可以维持
家庭局域网和普通互联网连接。
对客户端来说，只需要把默认网关从 OpenWrt 切回 MikroTik，就可以立即恢复直连。
二、IP 地址与设备规划
一个长期运行的网络，首先需要清晰的地址规划。地址如果随意分配，
后续做策略路由、端口转发和故障排查时会非常混乱。
2.1 示例地址规划
局域网网段： 192.168.16.0/24
MikroTik： 192.168.16.1
OpenWrt： 192.168.16.5
Mac： 192.168.16.10
Windows： 192.168.16.15
NAS： 192.168.16.55
Proxmox： 192.168.16.220
无线 AP： 192.168.16.2
DHCP 地址池： 192.168.16.100-192.168.16.199
2.2 固定地址的设备
建议以下设备使用静态地址或 DHCP 静态租约：
- MikroTik 主路由；
- OpenWrt 代理网关；
- NAS；
- Proxmox 或其他虚拟化服务器；
- 无线 AP；
- 需要端口转发或策略路由的客户端。
普通手机、平板和临时设备可以继续通过 DHCP 自动分配地址。
2.3 为什么 OpenWrt 必须使用固定地址
如果 OpenWrt 的地址发生变化，所有指向它的客户端网关、DNS 配置、
MikroTik 策略路由和监控规则都会同时失效。
因此，OpenWrt 地址必须长期固定，例如：
IP 地址： 192.168.16.5
子网掩码： 255.255.255.0
默认网关： 192.168.16.1
上游 DNS： 192.168.16.1
三、MikroTik 主路由配置
MikroTik 是整个架构的底座。在配置代理以前，必须先保证主路由本身稳定。
先保证没有 OpenWrt、没有 Xray 时，所有客户端仍然能够正常访问互联网。
3.1 修改前先备份
在 RouterOS Terminal 中执行：
/export file=before-openwrt-routing
/system backup save name=before-openwrt-routing
第一条命令导出可阅读的配置，第二条命令生成完整二进制备份。
3.2 Bridge 和 LAN 地址
假设 LAN Bridge 名称为 bridge：
/ip address
add address=192.168.16.1/24 interface=bridge comment="Main LAN Gateway"
如果现有网络已经正常运行，不要重复添加地址。部署前应先执行：
/ip address print
/interface bridge print
/interface bridge port print
3.3 DHCP 地址池
/ip pool
add name=lan-pool ranges=192.168.16.100-192.168.16.199
/ip dhcp-server
add name=lan-dhcp interface=bridge address-pool=lan-pool lease-time=1d disabled=no
/ip dhcp-server network
add address=192.168.16.0/24 \
gateway=192.168.16.1 \
dns-server=192.168.16.1 \
comment="Main LAN"
如果 MikroTik 已经配置 DHCP，只需要检查，不要重复创建。
/ip dhcp-server print
/ip dhcp-server network print
/ip dhcp-server lease print
3.4 给 OpenWrt 设置静态租约
可以让 OpenWrt 使用手动固定地址，也可以在 MikroTik 中绑定静态租约。
/ip dhcp-server lease
add address=192.168.16.5 \
mac-address=AA:BB:CC:DD:EE:FF \
comment="OpenWrt Proxy Gateway"
请把示例 MAC 地址替换成 OpenWrt 网卡的真实地址。
3.5 DNS 配置
MikroTik 可以作为普通直连设备的 DNS 入口，但不要让它与 OpenWrt 的代理 DNS
产生互相转发的环路。
/ip dns
set allow-remote-requests=yes \
servers=223.5.5.5,223.6.6.6 \
cache-size=8192KiB
这里的 DNS 仅用于示例。实际环境中可以使用运营商 DNS、公共 DNS 或 DoH。
3.6 基础 NAT
一般情况下，家庭宽带需要一条出口 NAT 规则：
/ip firewall nat
add chain=srcnat out-interface-list=WAN action=masquerade comment="LAN Internet NAT"
如果现有配置中已经存在 masquerade 规则，不要重复添加。
/ip firewall nat print
3.7 基础防火墙思路
一个合理的 MikroTik 防火墙，通常至少包含以下逻辑：
- 允许 established 和 related 连接；
- 丢弃 invalid 连接；
- 允许可信 LAN 管理路由器；
- 允许必要的 ICMP 和 ICMPv6；
- 禁止来自 WAN 的未授权访问；
- 只开放实际需要的端口。
示例逻辑：
/ip firewall filter
add chain=input connection-state=established,related action=accept comment="Accept established and related"
add chain=input connection-state=invalid action=drop comment="Drop invalid"
add chain=input in-interface-list=LAN action=accept comment="Allow LAN management"
add chain=input protocol=icmp action=accept comment="Allow ICMP"
add chain=input in-interface-list=WAN action=drop comment="Drop other WAN input"
这不是一套可以覆盖所有环境的完整防火墙。实际使用时必须结合现有接口列表、
IPv6、WireGuard 和端口转发规则调整。
3.8 FastTrack 注意事项
FastTrack 可以显著提高 RouterOS 的转发性能，但它也可能绕过部分 Mangle、
队列和策略路由处理。
如果后续由 MikroTik 自动把指定设备送往 OpenWrt，必须确认这些流量没有被
FastTrack 提前放行。
排查时可以临时禁用 FastTrack：
/ip firewall filter
disable [find action=fasttrack-connection]
测试完成后再重新启用：
/ip firewall filter
enable [find action=fasttrack-connection]
3.9 最安全的初始部署方式
初期不要马上在 MikroTik 中配置复杂策略路由。最安全的方法是：
- 所有设备默认网关继续使用 MikroTik；
- 只选择一台测试电脑；
- 把测试电脑网关手动修改为 OpenWrt；
- 完成全部验证以后，再考虑自动分流。
四、OpenWrt 旁路网关配置
OpenWrt 在这套架构中不是主路由，而是一台与其他设备处于同一网段的代理网关。
4.1 OpenWrt 网络参数
可以在 LuCI 中配置，也可以修改网络配置文件。
示例：
config interface 'lan'
option device 'br-lan'
option proto 'static'
option ipaddr '192.168.16.5'
option netmask '255.255.255.0'
option gateway '192.168.16.1'
list dns '192.168.16.1'
不同 OpenWrt 版本的配置格式可能略有差异，修改前应先备份：
cp /etc/config/network /etc/config/network.backup
cp /etc/config/dhcp /etc/config/dhcp.backup
cp /etc/config/firewall /etc/config/firewall.backup
4.2 关闭 OpenWrt DHCP
同一个二层网络中不应该同时存在两个未经规划的 DHCP 服务器。
如果 MikroTik 已经负责 DHCP，OpenWrt 的 LAN DHCP 应该关闭。
config dhcp 'lan'
option interface 'lan'
option ignore '1'
应用配置：
/etc/init.d/dnsmasq restart
确认 DHCP 端口监听情况：
ss -lunp | grep ':67'
4.3 检查 OpenWrt 默认路由
ip route
正常情况下应该类似：
default via 192.168.16.1 dev br-lan
192.168.16.0/24 dev br-lan scope link src 192.168.16.5
如果没有默认路由，OpenWrt 自己就无法访问 VPS，更不可能正常代理客户端流量。
4.4 先测试 OpenWrt 自身直连
在安装或启用代理以前，必须确认 OpenWrt 自己能够正常联网。
ping -c 4 192.168.16.1
ping -c 4 1.1.1.1
nslookup www.baidu.com
wget -O- https://www.cloudflare.com/cdn-cgi/trace
如果 IP 可以访问，但域名不能解析，说明问题在 DNS，而不是 Xray。
4.5 启用 IPv4 转发
sysctl net.ipv4.ip_forward
预期结果：
net.ipv4.ip_forward = 1
如果没有启用：
sysctl -w net.ipv4.ip_forward=1
OpenWrt 通常默认已经启用转发，但仍然值得确认。
4.6 检查防火墙区域
OpenWrt 需要允许来自 LAN 客户端的流量进入代理核心，并允许转发到 MikroTik。
uci show firewall
nft list ruleset
新版本 OpenWrt 主要使用 nftables。不要在不了解现有规则的情况下，
同时混用大量旧 iptables 脚本。
4.7 代理核心选择
常见选择包括：
- OpenClash：规则和订阅生态成熟，适合 Clash 配置。
- sing-box：架构现代，支持 TUN、规则集和多种协议。
- HomeProxy：更贴近 OpenWrt 原生管理方式。
- PassWall：协议支持广泛，但规则体系和插件结构较复杂。
- 原生 Xray：控制最直接，但需要自己处理透明代理和 DNS。
无论选择哪一个插件，底层逻辑都没有变化：
客户端流量
│
▼
OpenWrt 接管
│
▼
规则判断
│
├── DIRECT
├── REJECT
└── PROXY
五、Xray Reality 节点部署思路
远程 VPS 负责接收 OpenWrt 发出的代理连接，并以 VPS 的公网地址访问目标网站。
常见组合包括：
- VLESS + TCP + Reality + Vision；
- VLESS + TLS；
- Trojan + TLS；
- Shadowsocks；
- Hysteria2；
- TUIC。
对网页访问、软件下载和日常 TCP 应用来说，
VLESS + Reality + Vision 是一种常见选择。
5.1 服务端基础检查
uname -a
ip addr
ip route
ss -lntup
systemctl status xray
journalctl -u xray --no-pager -n 100
5.2 示例服务端结构
以下配置只用于展示参数关系，不能直接用于生产环境。
{
"log": {
"loglevel": "warning"
},
"inbounds": [
{
"listen": "0.0.0.0",
"port": 443,
"protocol": "vless",
"settings": {
"clients": [
{
"id": "替换为你自己的UUID",
"flow": "xtls-rprx-vision"
}
],
"decryption": "none"
},
"streamSettings": {
"network": "tcp",
"security": "reality",
"realitySettings": {
"dest": "目标站点.example.com:443",
"serverNames": [
"目标站点.example.com"
],
"privateKey": "替换为服务端私钥",
"shortIds": [
"替换为ShortID"
]
}
}
}
],
"outbounds": [
{
"protocol": "freedom",
"tag": "direct"
}
]
}
5.3 客户端需要一致的参数
| 参数 | 作用 |
|---|---|
| 服务器地址 | VPS 的 IP 或域名 |
| 端口 | 服务端监听端口 |
| UUID | 客户端身份认证 |
| Flow | 通常为 xtls-rprx-vision |
| Public Key | 由服务端 Reality 私钥生成 |
| Short ID | Reality 验证参数之一 |
| Server Name | 需要与服务端允许值匹配 |
| Fingerprint | 模拟常见 TLS 客户端特征 |
5.4 检查端口监听
ss -lntp | grep ':443'
正常结果类似：
LISTEN 0 4096 *:443 *:* users:(("xray",pid=1234,fd=8))
这只能证明 Xray 正在监听端口，不能证明 Reality 参数一定正确，也不能证明
客户端到服务器之间的网络链路没有问题。
5.5 443 端口并不等于一定最好
443 是标准 HTTPS 端口，但它并不会自动带来更低延迟、更高速度或更稳定的连接。
实际表现仍然取决于：
- 运营商对端口的调度和限制；
- 前置代理如何处理 TLS 流量；
- 链路丢包和拥塞；
- VPS 线路质量；
- TLS 指纹兼容性；
- 中间设备是否修改连接特征。
因此，端口选择应该以真实测试结果为准，而不是因为“大家都使用 443”。
六、DNS 分流设计
在代理系统中，DNS 不只是把域名转换成 IP 地址，它还直接影响规则匹配、
CDN 调度、IPv4 与 IPv6 选择，以及流量最终走直连还是代理。
6.1 理想的 DNS 逻辑
客户端发起 DNS 查询
│
▼
OpenWrt DNS 模块
│
├── 国内域名
│ │
│ ▼
│ 国内 DNS
│ │
│ ▼
│ DIRECT
│
└── 海外域名
│
▼
代理 DNS / 远程 DNS
│
▼
PROXY
6.2 常见 DNS 模式
Fake-IP
Fake-IP 会先向客户端返回一个保留地址，再由代理核心通过映射关系识别真实域名。
优点：
- 域名规则匹配准确；
- 客户端连接可以快速被代理核心接管；
- 适合透明代理。
可能的问题：
- 部分局域网设备不兼容；
- 某些应用会缓存 Fake-IP；
- 打印机、NAS、游戏和智能家居可能需要排除；
- 排障时看到的目标地址不是真实公网地址。
Redir-Host
Redir-Host 向客户端返回真实 IP，逻辑更直观，但域名与连接之间的关联可能没有
Fake-IP 那么直接。
6.3 避免 DNS 环路
错误示例：
MikroTik DNS
↓
OpenWrt DNS
↓
MikroTik DNS
↓
OpenWrt DNS
↓
无限循环
必须明确每一层的上游 DNS，不要让两个设备互相把对方设置为唯一上游。
6.4 浏览器 DoH 的影响
Chrome、Firefox 和部分应用可能自行启用 DoH。如果浏览器直接连接外部 DoH，
就可能绕过 OpenWrt 设定的 DNS 分流逻辑。
因此，出现“其他应用正常，只有浏览器异常”时，应检查浏览器安全 DNS设置。
6.5 IPv6 DNS 问题
如果域名同时返回 A 和 AAAA 记录，客户端可能优先尝试 IPv6。
如果 IPv6 没有被正确代理，可能出现：
- 网页首次连接很慢；
- 等待 IPv6 超时后才切换 IPv4；
- IPv4 测试正常，但浏览器仍打不开；
- 部分流量绕过代理。
排查命令：
nslookup example.com
nslookup -type=AAAA example.com
ping -4 example.com
ping -6 example.com
curl -4 https://example.com
curl -6 https://example.com
七、客户端与策略路由
7.1 第一阶段：手动指定网关
部署初期，建议只选择一台测试设备。
测试设备配置：
IP 地址： 192.168.16.10
子网掩码： 255.255.255.0
默认网关： 192.168.16.5
DNS： 192.168.16.5
普通设备继续使用：
默认网关： 192.168.16.1
DNS： 192.168.16.1
这种方式虽然需要手动修改，但排障非常简单。
当测试设备使用 MikroTik 网关时正常，使用 OpenWrt 网关时异常，
问题就基本可以锁定在 OpenWrt、DNS、代理核心或远程节点。
7.2 第二阶段：通过 DHCP 指定网关
部分 DHCP 服务器支持根据设备分配不同网关，但这种方案管理复杂，
并不是所有客户端都能可靠更新租约参数。
修改以后，应在客户端重新获取 DHCP：
Windows：
ipconfig /release
ipconfig /renew
macOS：
断开并重新连接网络，或更新 DHCP 租约
Linux：
dhclient -r
dhclient
7.3 第三阶段：MikroTik 自动策略路由
更高级的方式，是客户端仍然使用 MikroTik 作为默认网关，
再由 MikroTik 把指定设备流量转交给 OpenWrt。
客户端
│
▼
MikroTik
│
├── 普通设备 → WAN
│
└── 代理设备 → OpenWrt → MikroTik → WAN / VPS
这里最大的风险是形成路由环路。
必须明确排除：
- OpenWrt 自己发出的流量；
- VPS 服务器地址；
- 局域网网段；
- MikroTik 和 OpenWrt 管理地址；
- 已经处理过的连接。
在没有完全理解 RouterOS 路由标记和连接标记以前，不建议直接在生产网络中使用。
7.4 建议的规则分类
局域网地址 → DIRECT
中国大陆地址 → DIRECT
NAS / 打印机 → DIRECT
系统更新 → 根据实际需求
Google / GitHub → PROXY
AI 服务 → 指定节点
广告与恶意域名 → REJECT
VPS 自身地址 → DIRECT
八、真实数据流向
8.1 访问国内网站
客户端
│
▼
OpenWrt 192.168.16.5
│
▼
规则判断：国内地址
│
▼
DIRECT
│
▼
MikroTik 192.168.16.1
│
▼
运营商网络
│
▼
国内网站
8.2 访问海外网站
客户端
│
▼
OpenWrt
│
▼
规则判断：需要代理
│
▼
Xray / sing-box
│
▼
MikroTik
│
▼
运营商网络
│
▼
远程 VPS
│
▼
目标网站
8.3 访问局域网 NAS
客户端 192.168.16.10
│
▼
OpenWrt 判断为局域网地址
│
▼
DIRECT
│
▼
NAS 192.168.16.55
局域网地址必须直连。如果 NAS 流量被送到远程代理，通常说明私有地址排除规则缺失。
8.4 代理链场景
客户端
│
▼
机场前置代理
│
▼
自建 Xray 节点
│
▼
落地 VPS
│
▼
目标网站
多层代理可以改变出口 IP 和链路路径，但也会增加复杂度。
可能出现的问题包括：
- TLS 指纹在前置链路中表现异常；
- 前置代理限制特定目标端口；
- 连接复用导致握手特征变化；
- MTU 逐层降低；
- 故障时难以判断是哪一层中断。
九、部署后的验证方法
完成配置以后，不要只测试“能不能打开 Google”。应该按照从底层到上层的顺序验证。
9.1 第一层：局域网连接
ping 192.168.16.1
ping 192.168.16.5
ping 192.168.16.55
9.2 第二层：OpenWrt 互联网连接
ping -c 4 1.1.1.1
nslookup www.baidu.com
wget -O- https://www.cloudflare.com/cdn-cgi/trace
9.3 第三层：VPS 端口
nc -vz VPS_IP 443
如果系统没有 nc，可以使用：
telnet VPS_IP 443
9.4 第四层：代理出口
curl https://www.cloudflare.com/cdn-cgi/trace
curl https://api.ipify.org
curl https://ifconfig.me
对比直连和代理状态下的出口地址是否发生变化。
9.5 第五层：DNS
nslookup google.com 192.168.16.5
nslookup baidu.com 192.168.16.5
9.6 第六层：IPv4 与 IPv6
curl -4 https://www.cloudflare.com/cdn-cgi/trace
curl -6 https://www.cloudflare.com/cdn-cgi/trace
9.7 第七层：UDP 与 QUIC
网页能打开，不代表 UDP 一定正常。视频、游戏、语音和 HTTP/3 可能依赖 UDP。
可以通过实际应用测试，也可以暂时在浏览器中禁用 QUIC，
对比连接是否发生变化。
十、常见故障排查
10.1 所有设备都无法上网
优先检查：
- 光猫和运营商线路；
- MikroTik 是否获得公网或运营商地址；
- 默认路由是否存在；
- NAT 是否正常；
- DNS 是否可用。
/ip address print
/ip route print
/ip firewall nat print
/ip dns print
10.2 MikroTik 直连正常，OpenWrt 网关异常
说明主网络基本正常，问题大概率在以下位置：
- OpenWrt 默认路由；
- OpenWrt 防火墙；
- 代理核心未启动；
- DNS 分流错误；
- 节点不可用。
ip addr
ip route
ip rule
ss -lntup
logread | tail -n 100
nft list ruleset
10.3 IP 可以访问，域名打不开
这几乎可以直接指向 DNS。
ping 1.1.1.1
nslookup example.com
cat /etc/resolv.conf
10.4 国内网站正常，海外网站打不开
检查：
- 代理节点是否在线；
- 规则是否命中 PROXY；
- VPS 端口是否开放；
- Reality 参数是否一致；
- 服务器时间是否准确；
- DNS 是否返回异常地址。
10.5 VPS 端口监听正常，但节点仍无法使用
ss 显示监听，只能证明程序占用了端口。
仍然可能存在：
- UUID 错误；
- Public Key 错误；
- Short ID 不匹配；
- Server Name 不匹配；
- Flow 配置不一致；
- 客户端 TLS 指纹不兼容；
- 防火墙或云平台安全组拦截。
journalctl -u xray --no-pager -n 200
ss -lntp
ufw status verbose
nft list ruleset
10.6 手机运营商网络能连接，机场前置后不能连接
这个现象非常关键，因为它证明 VPS 和客户端参数不一定有问题。
差异发生在连接路径：
路径一：
手机运营商网络 → Xray VPS → 正常
路径二：
手机或电脑 → 机场代理 → Xray VPS → 异常
可能原因包括：
- 机场限制目标端口；
- 前置代理对 TLS 流量进行特殊处理；
- TLS 指纹兼容性问题；
- 前置出口 IP 被目标线路限制；
- 代理链中的 MTU 或连接复用问题。
此时最有价值的测试不是重装 VPS，而是更换连接路径、端口和指纹进行对比。
10.7 443 端口速度慢，其他端口反而正常
不要先入为主地认为 443 一定最好。
可以对比测试：
443
8443
2053
2083
2087
自定义高位端口
测试时应保证其他参数完全一致，每次只改变一个变量。
10.8 网页正常，但视频、游戏或语音异常
重点检查：
- UDP 是否被代理核心接管；
- QUIC 是否正常；
- MTU 是否过大；
- 线路是否存在 UDP 丢包；
- 规则是否把部分域名分配到不同节点。
10.9 能连接，但速度很慢
速度问题不能只看 VPS 面板标称带宽。
真正影响体验的是完整链路：
客户端
+
本地 Wi-Fi
+
家庭宽带
+
运营商国际出口
+
中转网络
+
VPS 入站
+
VPS 出站
+
目标网站
任何一段拥塞，最终速度都会下降。
10.10 OpenWrt 重启后代理失效
检查：
- 代理服务是否设置为开机启动；
- TUN 接口是否正确创建；
- 策略路由表是否恢复；
- DNS 服务是否启动；
- 系统时间是否同步。
service
logread
ip addr
ip rule
ip route show table all
date
10.11 无法访问 NAS 或路由器管理页面
通常是局域网地址被错误代理。
应确保以下地址直连：
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
127.0.0.0/8
169.254.0.0/16
224.0.0.0/4
10.12 出现路由环路
常见表现：
- 延迟快速升高；
- TTL 很快耗尽；
- MikroTik 和 OpenWrt 流量持续增加；
- 客户端完全无法访问互联网。
使用 traceroute 检查：
traceroute 1.1.1.1
traceroute VPS_IP
如果路径在 MikroTik 和 OpenWrt 之间反复跳转，就说明策略路由设计存在环路。
10.13 FastTrack 导致策略路由失效
如果关闭 FastTrack 后代理恢复正常，说明相关连接在进入策略规则以前，
已经被 FastTrack 处理。
正确做法不是永久关闭 FastTrack，而是只让不需要策略处理的连接进入 FastTrack。
10.14 DNS 查询正常，但浏览器仍打不开
检查：
- 浏览器 DoH；
- HTTP/3 和 QUIC；
- IPv6 优先；
- 浏览器缓存；
- 系统代理与透明代理是否叠加。
10.15 日志里没有明显错误
没有错误日志，不代表链路一定正常。部分问题发生在程序以外，例如：
- 运营商丢包；
- 中间网络重置连接；
- MTU 黑洞；
- 前置代理修改连接行为；
- 目标网站拒绝出口 IP。
此时应使用抓包、路径对比和单变量测试，而不是继续盯着同一份日志。
十一、性能优化建议
11.1 不要在多个位置重复代理
如果 OpenWrt 已经透明代理，客户端通常不需要再开启系统级代理软件。
多层接管可能导致：
- 流量重复封装；
- DNS 路径混乱；
- 规则互相冲突；
- 排障难度增加。
11.2 使用有线连接测试基准性能
在判断 VPS 或代理性能以前，应先排除 Wi-Fi 干扰。
最好使用有线客户端连接 MikroTik 或交换机进行测试。
11.3 MTU 与 MSS
多层隧道会增加额外头部。如果 MTU 过大，可能产生分片或丢包。
检查接口 MTU：
ip link
测试不分片包：
ping -M do -s 1472 1.1.1.1
ping -M do -s 1400 1.1.1.1
不要盲目把 MTU 改得很低。正确方法是逐步测试并记录结果。
11.4 BBR
Linux VPS 可以检查是否使用 BBR：
sysctl net.ipv4.tcp_congestion_control
sysctl net.core.default_qdisc
常见结果：
net.ipv4.tcp_congestion_control = bbr
net.core.default_qdisc = fq
BBR 可以改善部分高延迟和有损链路的 TCP 表现，但它不能修复严重丢包、
线路绕路或运营商拥塞。
11.5 DNS 缓存
合理的 DNS 缓存可以减少重复查询，提高网页首次连接速度。
但缓存时间过长，也可能导致 CDN 地址变化后仍然使用旧结果。
11.6 节点选择优先看真实路径
节点地理位置近，不代表网络路径一定短。
建议结合以下工具：
ping
mtr
traceroute
nexttrace
curl
iperf3
最终仍然要以日常网页、视频、下载和应用体验为准。
11.7 每次只改变一个变量
排查和优化时，不要同时更换：
- 协议；
- 端口；
- VPS；
- DNS；
- TLS 指纹；
- 代理核心。
如果一次改变五个参数，即使问题消失，也无法知道到底是哪一个参数起作用。
真正可靠的网络优化，本质上是控制变量实验。
十二、安全与备份
12.1 MikroTik 备份
/export file=router-config
/system backup save name=router-backup
12.2 OpenWrt 备份
可以通过 LuCI 生成系统备份，也可以备份关键目录：
sysupgrade -b /tmp/openwrt-backup.tar.gz
12.3 Xray 配置备份
cp /usr/local/etc/xray/config.json /root/xray-config-backup.json
如果使用管理面板，还应备份面板数据库和证书。
12.4 不要公开敏感参数
发布截图或文章时应隐藏：
- UUID；
- Reality Private Key；
- 完整 Public Key；
- Short ID；
- 服务器真实管理端口；
- SSH 密钥；
- 管理面板密码；
- 家庭公网 IP。
12.5 SSH 安全
建议：
- 使用密钥登录；
- 关闭密码登录；
- 禁止 root 直接使用密码登录；
- 限制管理端口来源；
- 安装 Fail2ban 或等效防护；
- 定期安装安全更新。
12.6 永远保留回退路径
不要让自己的电脑只有通过 OpenWrt 才能访问 MikroTik。
至少应保留一种方式：
- 手动设置 MikroTik 网关；
- 独立管理 VLAN；
- 有线直连管理口；
- RouterOS MAC WinBox；
- 本地控制台。
十三、推荐的实际部署顺序
- 备份 MikroTik、OpenWrt 和服务器配置。
- 确认 MikroTik 直连网络完全正常。
- 给 OpenWrt 设置固定地址。
- 关闭 OpenWrt 的 DHCP 服务。
- 确认 OpenWrt 自己可以正常访问互联网。
- 部署并测试远程 Xray 节点。
- 在 OpenWrt 中导入节点。
- 只让一台电脑使用 OpenWrt 网关。
- 测试国内网站、海外网站和局域网设备。
- 测试 DNS、IPv4、IPv6、TCP 和 UDP。
- 连续运行一段时间，观察日志和稳定性。
- 确认稳定后，再逐步增加设备。
- 最后才考虑由 MikroTik 自动执行策略路由。
这套顺序看起来比一键接管全网慢，但它能把每一步的变量控制在最小范围。
一旦出现问题，可以立刻知道故障是在哪一步加入的。
十四、总结
OpenWrt、MikroTik 和 Xray 并不是三个互相替代的产品。
它们分别解决不同层级的问题：
MikroTik
=
稳定的主路由、DHCP、防火墙和网络底座
OpenWrt
=
灵活的透明代理、DNS 分流和策略控制平台
Xray
=
本地网络与远程 VPS 之间的加密传输层
把所有功能塞进一台路由器，表面上设备更少，实际上只是把复杂性隐藏在一个黑盒中。
把职责拆开以后，设备数量虽然增加了，但每一层的边界更加清晰：
- 主网络故障，检查 MikroTik。
- 只有代理设备异常，检查 OpenWrt。
- 节点无法握手，检查 Xray 和链路。
- IP 能访问但域名异常，检查 DNS。
- 直连正常、前置代理异常，检查代理链和 TLS 特征。
对我来说，这套架构最大的价值并不是速度，而是可维护性。
当网络发生故障时，我不需要靠猜，也不需要把所有设备全部重装。
我只需要沿着真实的数据路径，一层一层验证，就能找到连接中断的位置。
一个真正稳定的家庭网络，不是永远不会出问题，而是在问题出现以后，
仍然拥有清晰的日志、可靠的回退方式和可以重复验证的排查流程。
这也是我最终选择 MikroTik + OpenWrt + Xray 分层架构的原因：
稳定归稳定，代理归代理，出口归出口。