docs: update example

README.md

@@ -12,7 +12,7 @@
 
 + ✅ 完全兼容 IPv6 ，支持 SLAAC 地址分配，RDNSS 与 DNSSL 配置
 
-+ ⏳ 内置DHCP与DHCPv6服务器，支持IP地址自动分配
++ ✅ 内置 DHCP 与 DHCPv6 服务器，支持 IP 地址自动分配
 
 ## 拓扑模型
 
@@ -158,7 +158,7 @@ network:
 asset:
   disable: false
   update:
-    cron: "0 0 4 * * *"  # 每天凌晨4点更新
+    cron: "0 5 6 * * *"  # 每天凌晨06点05分更新
     proxy: "socks5://192.168.2.4:1080"  # 通过 socks5 代理更新资源
     url:
       geoip.dat: "https://github.com/Loyalsoldier/v2ray-rules-dat/releases/latest/download/geoip.dat"
@@ -194,7 +194,7 @@ custom:
     - "echo Goodbye"
 ```
 
-> 本功能用于注入自定义功能，基于 Alpine 自带的 ash 执行，可能不支持部分 bash 语法
+> 本功能用于注入自定义功能，基于 Alpine 的 ash 执行，可能不支持部分 bash 语法
 
 + `pre` ：自定义脚本命令，在代理启动前执行，默认为空
 
@@ -204,6 +204,8 @@ custom:
 
 > `radvd` 有大量配置选项，`XProxy` 均对其保持兼容，以下仅介绍部分常用选项，更多详细参数可参考[man文档](https://www.systutorials.com/docs/linux/man/5-radvd.conf/)
 
+> 注意以下的 `on` 与 `off` 为字符串，但在部分 YAML 库中可能被解析成布尔值，为了安全起见，下游项目请注意转换时添加引号限定
+
 ```yaml
 # 以下配置仅为示范
 radvd:
@@ -241,7 +243,7 @@ radvd:
 
 + `log` ：RADVD 日志级别，可选 `0-5`，数值越大越详细，默认为 `0`
 
-+ `dev` ：RADVD 运行的网卡，`enable` 为 `true` 时必选，一般与 `network` 中配置的网卡相同，默认为空
++ `dev` ：执行 RA 广播的网卡，`enable` 为 `true` 时必选，一般与 `network` 中配置相同，默认为空
 
 + `enable` ：是否启动 RADVD，默认为 `false`
 
@@ -277,7 +279,7 @@ radvd:
 
 ### DHCP服务选项
 
-> DHCP 服务基于 [ISC-DHCP](https://www.isc.org/dhcp/) 项目提供
+> DHCP 与 DHCPv6 功能由 [ISC-DHCP](https://www.isc.org/dhcp/) 项目提供
 
 ```yaml
 # 以下配置仅为示范
@@ -312,7 +314,7 @@ dhcp:
 
 ### 1. 初始配置
 
-> XProxy 基于 macvlan 网络，开启混杂模式可以捕获非本机物理网卡的数据包，以此模拟出不同 MAC 地址的网卡
+> XProxy 基于 macvlan 网络，开启网卡混杂模式后可以捕获非本机 MAC 地址的数据包，以此模拟出不同 MAC 地址的网卡
 
 ```
 # 开启混杂模式，网卡按实际情况指定
@@ -329,7 +331,7 @@ shell> modprobe ip6table_filter
 shell> docker network create -d macvlan \
   --subnet={IPv4网段} --gateway={IPv4网关} \
   --subnet={IPv6网段} --gateway={IPv6网关} \
-  --ipv6 -o parent=eth0 macvlan  # 此处指定eth0网卡，需按实际调整
+  --ipv6 -o parent=eth0 macvlan  # 在eth0网卡上运行
 ```
 
 ### 2. 开始部署
@@ -366,6 +368,8 @@ shell> docker run --restart always \
 
 + `log` ：存储日志文件
 
++ `dhcp` ：存储 DHCP 数据库文件（仅当 DHCP 服务开启）
+
 **路由资源文件夹**
 
 `assets` 目录默认放置 `geoip.dat` 与 `geosite.dat` 路由规则文件，分别存储IP与域名归属信息，在 `update` 中配置的自动更新将保存到此处；本目录亦可放置自定义规则文件，在[路由配置](https://xtls.github.io/config/routing.html#ruleobject)中以 `ext:${FILE}:tag` 格式引用。
@@ -391,7 +395,9 @@ shell> docker run --restart always \
 
 `log` 目录用于放置日志文件
 
-+ `access.log` 记录代理流量连接
++ `xproxy.log` 记录 XProxy 工作信息
+
++ `access.log` 记录代理流量连接信息
 
 + `error.log` 记录代理连接错误信息
 
@@ -417,7 +423,7 @@ network:
 
 asset:
   update:
-    cron: "0 0 4 * * *"
+    cron: "0 5 6 * * *"
     url:
       geoip.dat: "https://github.com/Loyalsoldier/v2ray-rules-dat/releases/latest/download/geoip.dat"
       geosite.dat: "https://github.com/Loyalsoldier/v2ray-rules-dat/releases/latest/download/geosite.dat"
@@ -487,7 +493,7 @@ shell> /etc/init.d/networking restart
 
 ## 演示实例
 
-> 由于 XProxy 涉及较为复杂的网络配置，这里准备了两个详细的实例供您理解
+> 由于 XProxy 涉及较为复杂的网络配置，这里准备了两个详细的实例供您了解
 
 + 实例1. [使用 XProxy 绕过校园网认证登录](./docs/example_1.md)
 

cmd/config/default.go

@@ -15,7 +15,7 @@ network:
 
 asset:
   update:
-    cron: "0 0 4 * * *"
+    cron: "0 5 6 * * *"
     url:
       geoip.dat: "https://github.com/Loyalsoldier/v2ray-rules-dat/releases/latest/download/geoip.dat"
       geosite.dat: "https://github.com/Loyalsoldier/v2ray-rules-dat/releases/latest/download/geosite.dat"

docs/example_1.md

@@ -18,9 +18,11 @@
 
 ### 代理协议
 
-首先，从速度上考虑，我们应该选用 socks 层面的代理，它在代理服务器上的部署更方便，且 CPU 负载较低，缺点则是 ICMP 流量无法被代理，不过绝大多数情况下并不会用到公网 ICMP 流量（例如 PING 命令）；其次，由于存在高峰期 QoS，应使用基于 TCP 的代理协议，此外，为了避开校园网的流量审查，我们应该将流量加密传输；最后，由于软路由性能一般较差，而代理服务器无需考虑协议兼容性问题，我们可以考虑基于 XTLS 的传输方式，它可以显著降低代理 https 流量时的性能开销。
+从部署成本与便捷性方面考虑，socks 类代理是最合适的工具：无需修改服务器网卡路由表等配置，方便多级负载均衡，软件只在用户态运行，实测速度也相对 `IPSec` 、`L2TP` 等协议更有优势；但 socks 代理只接收 TCP 与 UDP 流量，ICMP 流量无法被直接代理（例如 PING 命令），不过大多数情况下我们不会用到公网 ICMP 流量，如果确实需要也可以曲线救国给它补上。
 
-综上，选择 VLESS + XTLS 或者 Trojan + XTLS 代理是当前网络环境下的最优解。
+在选定代理类型后，我们需要考虑具体的传输方式，由于存在 QoS 问题，这里应该倾向于选择基于 TCP 的代理方式，同时为了避免校园网的流量审查，我们应该将流量加密传输。考虑到软路由性能一般较差，而自建的代理服务器无需考虑协议兼容性问题，这里更建议选择基于 XTLS 的传输方式，它避开了对 TLS 流量的二次加密，可以显著降低代理 https 流量时的性能开销，提升性能上限；至于延迟方面的问题，如果选择 `gRPC` 等协议，虽然有 0-rtt 握手的延迟优势，但这种场景下延迟一般不高（甚至服务器可以直接部署在校内），用微弱的延迟优势换取性能开销并不值得，且前者也可以开启 mux 多路复用来优化延迟。
+
+既然我们已经选择 XTLS 方式，那使用轻量的无加密类型（在加密的 XTLS 隧道里传输）是当前网络的最优解，譬如 VLESS 或者 Trojan 协议，下面将用 VLESS + XTLS 代理进行配置演示；当然，具体的选择还是取决于您的实际应用场景，只要按需调整 XProxy 的配置文件即可。
 
 ### 初始化配置
 
@@ -54,7 +56,7 @@ shell> docker run --restart always \
 
 ### 参数配置
 
-我们将三台服务器分别称为 `nodeA` ，`nodeB` 与 `nodeC` ，其中只有 `nodeC` 支持IPv6网络；此外，我们在内网分别暴露3个 socks 服务端口，用于检测三台服务器的可用性。
+我们将三台服务器分别称为 `nodeA` ，`nodeB` 与 `nodeC` ，其中只有 `nodeC` 支持IPv6网络；此外，我们在内网分别暴露 3 个 socks5 端口，分别用于检测服务器的可用性。
 
 由于校园网无 IPv6 支持，这里 IPv6 上游网关可以不填写；虚拟网关对内网发布 RA 通告，让内网设备使用 SLAAC 配置网络地址，同时将其作为 IPv6 网关；此外，如果路由器开启了 DHCP 服务，需要将默认网关改为 `192.168.2.2` ，也可以启用 XProxy 自带的 DHCPv4 服务。
 
@@ -188,3 +190,95 @@ shell> docker restart scutweb
 ```
 
 最后，验证代理服务是否正常工作，若出现问题可以查看 `/etc/scutweb/log` 文件夹下的日志，定位错误原因。
+
+### 代理 ICMP 流量
+
+> 这一步仅用于修复 ICMP 代理，无此需求可以忽略
+
+由于 socks5 代理服务不支持 ICMP 协议，当前搭建的网络只有 TCP 与 UDP 发往外网，即使在上文我们注入了一段命令用于劫持 PING 流量，但是返回的仅仅是虚假结果，并没有实际意义；所以如果对这个缺陷不满，您可以考虑使用以下方法修复这个问题。
+
+为了代理 ICMP 流量，我们必须选择网络层的 VPN 工具，从简单轻量可用方面考虑，`WireGuard` 比较适合当前应用场景：TCP 与 UDP 流量走 VLESS + XTLS 代理，ICMP 流量进入 WireGuard ，而 WireGuard 本身使用 UDP 协议传输，这些数据包通过 Xray 隧道再次代理送到远端服务器，解开后将 ICMP 流量送至公网；这种方式虽然略显繁杂，但实际场景中 ICMP 流量很少且数据包不大，并不存在性能问题。
+
+具体实现上，我们需要在容器中安装 WireGuard 工具包，然后在 XProxy 中配置启动注入脚本，开启 WireGuard 对 ICMP 流量的代理。
+
+1. 拉取 WireGuard 安装包
+
+XProxy 容器默认不自带 WireGuard 功能，需要额外安装 `wireguard-tools` 包，您可以在原有镜像上添加一层，或是使用以下方式安装离线包。
+
+> 以下代码用于生成 Alpine 的 WireGuard 安装脚本，您也可以选择手动拉取 apk 安装包
+
+```python
+alpine = '3.16'
+import os, re, sys
+
+if len(sys.argv) != 2:
+    print('Invalid argument')
+    sys.exit(1)
+workDir = os.path.join(os.path.dirname(os.path.realpath(__file__)), sys.argv[1])
+output = os.popen(' '.join([
+    'docker', 'run', '--rm', '-it', '-v', '%s:/pkg' % workDir, '-w', '/pkg',
+    'alpine:%s' % alpine, 'sh', '-c', '\'apk update && apk fetch -R %s\'' % sys.argv[1]
+])).read()
+print("%(line)s\n%(msg)s%(line)s" % {'line': '=' * 88, 'msg': output})
+with open(os.path.join(workDir, 'setup'), 'w') as script:
+    script.write("#!/bin/sh\ncd `dirname $0`\napk add --no-network " + ' '.join([
+        s + '.apk' for s in re.findall(r'Downloading (\S+)', output)
+    ]) + "\n")
+os.system('chmod +x %s' % os.path.join(workDir, 'setup'))
+```
+
+```
+# fetch.py 为上述脚本
+
+shell> cd /etc/scutweb
+shell> mkdir -p ./toolset && cd ./toolset
+shell> python3 fetch.py wireguard-tools  # 拉取wireguard-tools依赖
+···
+···
+```
+
+拉取成功后将生成 `wireguard-tools` 文件夹，包含多个依赖的 `.apk` 安装包与 `setup` 安装脚本
+
+2. 写入 WireGuard 配置文件
+
+一个典型的客户端配置文件如下：
+
+```
+[Interface]
+PrivateKey = 客户端私钥
+
+[Peer]
+PublicKey = 服务端公钥
+Endpoint = 服务器IP:端口
+AllowedIPs = 0.0.0.0/0
+```
+
+将其保存至 `/etc/scutweb/config/wg.conf`
+
+3. 容器注入 WireGuard 服务
+
+WireGuard 在这里使用 `192.168.1.0/24` 的 VPN 网段，客户端 IP 地址为 `192.168.1.2`，注意服务端应允许 `192.168.2.2/24` 网段，否则必须在容器中多做一层 NAT 才能代理。
+
+此外，XProxy 默认没有加入网关自身的代理，只在 `PREROUTING` 链上劫持流量，因此这里需要修改 `OUTPUT` 链，让 WireGuard 的流量被 XProxy 代理；将发往 WireGurad 服务器的流量打上标志 `0x1`，该数据包就会被重新路由到 `PREROUTING` 链上（netfilter 特性），从而进行透明代理。
+
+```yaml
+custom:
+  pre:
+    - /xproxy/toolset/wireguard-tools/setup  # 安装离线包
+    - ip link add wg0 type wireguard
+    - wg setconf wg0 /xproxy/config/wg.conf  # 加载配置文件
+    - ip addr add 192.168.1.2/24 dev wg0  # 添加本机WireGuard地址
+    - ip link set mtu 1420 up dev wg0  # 启动VPN服务
+    - ip rule add fwmark 51820 table 51820
+    - ip route add 0.0.0.0/0 dev wg0 table 51820  # WireGuard路由表
+    - iptables -t mangle -N WGPROXY
+    - iptables -t mangle -A WGPROXY -d 127.0.0.0/8 -j RETURN
+    - iptables -t mangle -A WGPROXY -d 192.168.2.0/24 -j RETURN
+    - iptables -t mangle -A WGPROXY -d 169.254.0.0/16 -j RETURN
+    - iptables -t mangle -A WGPROXY -d 224.0.0.0/3 -j RETURN
+    - iptables -t mangle -A WGPROXY -p icmp -j MARK --set-mark 51820  # ICMP流量送至WireGuard路由表
+    - iptables -t mangle -A PREROUTING -j WGPROXY
+    - iptables -t mangle -A OUTPUT -p udp -d 服务器IP –-dport 服务器端口 -j MARK --set-mark 1  # 重定向到PREROUTING
+```
+
+配置完成后，重启 XProxy 容器生效，在内网设备上执行 PING 命令，如果返回正常延迟则配置成功。

docs/example_2.md

@@ -6,7 +6,7 @@
 
 ![Network](./img/example_2.png)
 
-> 此处网络拓扑仅为讲解使用，实际使用时可以让光猫桥接减少性能浪费，不过目前大部分新版光猫性能不存在瓶颈，千兆级别下基本没有压力。
+> 此处网络拓扑仅为讲解使用，实际使用时可以让光猫桥接减少性能浪费，不过目前大部分新版光猫不存在性能瓶颈，千兆级别下基本没有压力。
 
 正常情况下，大部分家庭宽带为：光猫对接上游网络，使用宽带拨号获取运营商分配的 IPv4 地址与 IPv6 前缀，在 LAN 侧提供网络服务，其中 IPv4 为 NAT 方式，IPv6 发布 RA 广播，同时运行 DHCPv6 服务；路由器在 IPv4 上 NAT ，在 IPv6 上桥接，内网设备统一接入路由器。
 
@@ -16,21 +16,21 @@
 
 代理内核需要区分出哪些流量可以直连，哪些流量需要送往代理服务器，为了更准确地分流，这里需要开启嗅探功能，获取访问的域名信息，同时允许流量重定向（目标地址修改为域名，送至代理服务器解析，避开 DNS 污染）；
 
-目前路由资源中包含了一份国内常见域名列表，如果嗅探后的域名在其中，那可以直接判定为直连流量，但是对于其他流量，即使它不在列表内，但仍可能是国内服务，我们不能直接将它送往代理服务器；因此下一步我们需要引出分流的核心规则，它取决于 DNS 污染的一个特性：受污染的域名返回解析必然为境外 IP ，基于这个原则，我们将嗅探到的域名使用国内 DNS 进行一次解析，如果结果是国内 IP 地址，那就直连该流量，否则发往代理，IPv4 与 IPv6 均使用该逻辑分流。
+目前路由资源中包含了一份国内常见域名列表（即 `geosite.dat` ，XProxy 已集成），如果嗅探后的域名在其中，那可以直接判定为直连流量，但是对于其他流量，即使它不在列表内，但仍可能是国内服务，我们不能直接将它送往代理服务器；因此下一步我们需要引出分流的核心规则，它取决于 DNS 污染的一个特性：受污染的域名返回解析必然为境外 IP ，基于这个原则，我们将嗅探到的域名使用国内 DNS 进行一次解析，如果结果是国内 IP 地址，那就直连该流量，否则发往代理服务器，IPv4 与 IPv6 均使用该逻辑分流。
 
 如果有可能的话，您可以在内网搭建一个无污染的解析服务，比如 [ClearDNS](https://github.com/dnomd343/ClearDNS)，它的作用在于消除 DNS 污染，准确地给出国内外的解析地址，这样子可以在分流时就不用多做一次 DNS 解析，减少这一步导致的延迟（DNS 流量通过代理送出，远程解析以后再返回，其耗时较长且不稳定），无污染 DNS 可以更快更准确地进行分流。
 
 ### 网络配置
 
-网络地址方面，内网 IPv4 段由我们自己决定，这一部分取决于路由器设置的 LAN 侧 IP 段，我们假设为 `192.168.2.0/24` ，其中路由器地址为 `192.168.2.1` ，虚拟网关分配为 `192.168.2.2` ，由于 IPv4 部分由路由器隔离，这里不需要修改光猫配置；虚拟网关上游配置为路由器地址，修改内网 DHCP 服务，让网关指向 `192.168.2.2` 。
+网络地址方面，内网 IPv4 段由我们自己决定，这一部分取决于路由器设置的 LAN 侧 IP 段，我们假设为 `192.168.2.0/24` ，其中路由器地址为 `192.168.2.1` ，虚拟网关分配为 `192.168.2.2` ，由于 IPv4 部分由路由器 NAT 隔离，这里不需要修改光猫配置；虚拟网关上游配置为路由器地址，修改内网 DHCP 服务，让网关指向 `192.168.2.2` 。
 
 IPv6部分，由于路由器桥接，地址分配等操作均为光猫负责，它拥有一个链路本地地址，在 LAN 侧向内网发送 RA 广播，一些光猫还会开启 DHCPv6 服务，为内网分配 DNS 等选项；RA 通告发布的 IPv6 前缀一般为运营商分配的 64 位长度地址，内网所有设备将获取到一个独立的 IPv6 地址（部分地区也有做 NAT6 的，具体取决于运营商），我们要做的就是将这部分工作转移给虚拟网关来完成。
 
 在开始之前，我们需要先拿到光猫分配的 IPv6 前缀与网关（即光猫的链路地址），由于光猫默认会发布 RA 广播，你可以直接从当前接入设备上获取这些信息，也可以登录光猫管理页面查看（登录账号与密码一般会印在光猫背面）；这里假设运营商分配的 IPv6 网段为 `2409:8a55:e2a7:3a0::/64` ，光猫地址为 `fe80::1`（绝大多数光猫都使用这个链路地址），虚拟网关的上游应该配置为光猫链路地址，而自身地址可以在分配的 IPv6 网段中任意选择，方便起见，我们这里配置为 `2409:8a55:e2a7:3a0::` 。
 
-虚拟网关需要对内网发布 RA 通告，广播 `2409:8a55:e2a7:3a0::/64` 这段地址，接收到这段信息的设备会将虚拟网关作为公网 IPv6 的下一跳地址（即网关地址）；但是这种情况下，不应该存在多个 RA 广播源同时运行，所以需要关闭光猫的 RA 广播功能，如果不需要DHCPv6，也可以一并关闭；这一步在部分光猫上需要超级管理员权限，一般情况下，你可以在网络上搜索到不同型号光猫的默认超级管理员账号密码，如果无法成功，可以联系宽带师傅帮忙登入。
+虚拟网关需要对内网发布 RA 通告，广播 `2409:8a55:e2a7:3a0::/64` 这段地址，接收到这段信息的设备会将虚拟网关作为公网 IPv6 的下一跳地址（即网关链路地址）；但是这种情况下，不应该存在多个 RA 广播源同时运行，所以需要关闭光猫的 RA 广播功能，如果不需要 DHCPv6 功能，这里也可以一并关闭；这一步在部分光猫上需要超级管理员权限，一般情况下，你可以在网络上搜索到不同型号光猫的默认超级管理员账号密码，如果无法成功，可以联系宽带师傅帮忙登入。
 
-这也是IPv6在代理方面的缺点，它将发送 RA 广播的链路地址直接视为路由网关，且该地址无法通过其他协议更改，我们没法像 DHCPv4 一样直接配置网关地址，这在透明代理时远没有 IPv4 方便，只能将 RA 广播源放在网关上。
+这是 IPv6 在代理方面的缺点，它将发送 RA 广播的链路地址直接视为路由网关，且该地址无法通过其他协议更改，我们没法像 DHCPv4 一样直接配置网关地址，这在透明代理时远没有 IPv4 方便，只能将 RA 广播源放在网关上。
 
 ### 启动服务
 
@@ -58,7 +58,7 @@ shell> docker run --restart always \
 
 ### 参数配置
 
-在设计上，应该配置四个出口，分别为 IPv4直连、IPv4代理、IPv6直连、IPv6代理，这里创建 4 个对应的 socks5 接口 `direct` 、`proxy` 、`direct6` 、`proxy6` ，用于检测对应出口是否正常工作。
+在设计上，应该配置四个出口，分别为 IPv4 直连、IPv4 代理、IPv6 直连、IPv6 代理，这里创建 4 个对应的 socks5 接口 `direct4` 、`proxy4` 、`direct6` 、`proxy6` ，用于检测对应出口是否正常工作。
 
 此外，我们需要判断 IP 与域名的地理信息，而该数据库一直变动，需要持续更新；由于该项目的 Github Action 配置为 UTC 22:00 触发，即 UTC8+ 的 06:00 ，所以这里配置为每天早上 06 点 05 分更新，延迟 5 分钟拉取当日的新版本路由资源。
 
@@ -125,14 +125,14 @@ asset:
       "tag": "direct4",
       "protocol": "freedom",
       "settings": {
-        "domainStrategy": "UseIP"
+        "domainStrategy": "UseIPv4"
       }
     },
     {
       "tag": "direct6",
       "protocol": "freedom",
       "settings": {
-        "domainStrategy": "UseIP"
+        "domainStrategy": "UseIPv6"
       }
     },
     {