荒岛
记录下排查与解决过程。起因：一台日本VPS（Debian12）用脚本测试能解锁DMMTV，但是搭建了代理用浏览器访问却解不了。。
一开始走弯路了，有点怀疑是解锁脚本测试的不准确，但是我还是更愿意相信是自己环境的问题，毕竟解锁脚本经过多人使用出错的概览不大，然后又以为是DMM用了WebRTC，给浏览器装了个关闭WebRTC的扩展还是不行。。
后来我发现这个VPS是双栈网络，有IPv6地址，然后又跑了一遍解锁脚本测试发现IPv6是不能解锁的，我就猜测是不是访问DMMTV的时候流量走了IPv6？我试着把IPv6关闭后，确实就能解锁了，到这里就能够确定是IPv6的问题了，但是我还是想保留IPv6，平时还是会用到IPv6的，直接关掉有点太鲁莽了。
我知道Linux系统中有一个gai.conf的配置文件，它可以控制系统如何选择地址，尤其是当系统同时支持IPv4和IPv6时，它决定了应用优先使用IPv4还是IPv6，我试着编辑gai.conf：
nano /etc/gai.conf
取消如下内容的注释，以启用IPv4优先：
precedence ::ffff:0:0/96 100
但是这并不能解决我的问题，虽然在VPS内curl还有ping等工具确实优先使用IPv4了，但作为代理服务器，我用浏览器访问DMMTV还是不能解锁。。。百思不得其解，突然想到会不会是代理节点的问题？我使用的是Remnawave面板，这台VPS安装的是Docker运行的Remnanode，使用的网络模式是host：
services:
remnanode:
container_name: remnanode
hostname: remnanode
image: remnawave/node:latest
restart: always
network_mode: host
env_file:
- .env
host网络默认应该也是没有启用IPv6支持的，但我记不太清楚，所以特地验证了一下，确实是没有启用IPv6：
docker network inspect host
我不知道这里的IPv6启用与否是否真的会影响到容器内的程序，所以我想看看容器的日志，我先用这个命令查看：
docker compose logs -f
发现看不到真正有用的日志，因为Remnanode实际上是用的Xray-core内核，它这个容器相当于是套了一层supervisor，最外层看不到Xray-core内核的日志，所以通过下面的命令我终于看到Xray-core内核的日志了：
docker exec -it remnanode tail -n +1 -f /var/log/supervisor/xray.out.log
按道理来说应该挂载一个volume，把这个log保存到宿主机的，当时配置的时候疏忽了，这日志一看就知道问题所在了，Xray-core一直在用IPv6去连接DMMTV。。。接着去搜Xray-core的文档，发现这段话：
可以通过修改 “domainStrategy”: “UseIPv6″来控制对应用户的访问方式 实测优先级要高于系统本身的 gai.config
难怪我之前配置gai.conf不起作用，现在就明朗了= =在Remnawave面板，修改配置文件，在出站配置domainStrategy：
"settings": {
"domainStrategy": "UseIPv4"
}
如图所示：
再次测试，DMMTV就能够正常解锁了= =
