QQ音乐(p2p/udp?)导致VPN断开
操作系统
iOS
系统版本
iOS 17.5.1(21F90):iPhone 15 Pro、iPhone 11 Pro Max
安装类型
sing-box 原始命令行程序
如果您使用图形客户端程序,请提供该程序版本。
1.9.3
版本
No response
描述
使用QQ音乐听歌听一会就会导致VPN断开。(下面有我自己的解决方法。)
之前提过一次 https://github.com/SagerNet/sing-box/issues/1858 (可忽略),我希望我这里能提供更多信息,所以又进行测试后再提一次。
断开后 metacubexd 的截图。
重现方式
我获取日志的代码
因为我不知道怎么能拿到iOS上的日志文件。所以在手机上点了 Enabled 后马上运行这个脚本来监听ws拿日志。
import * as fs from "fs";
const ws = new WebSocket("ws://192.168.31.92:9090/logs?token=&level=trace");
const filePath = "mobile.log";
ws.addEventListener("open", () => {
console.log("WebSocket 连接已打开");
fs.writeFileSync(filePath, "");
fs.appendFileSync(filePath, `启动时间: ${new Date().toLocaleString()}\n`);
});
ws.addEventListener("message", (event) => {
const message = `收到消息: ${event.data}`;
console.log(message);
fs.appendFileSync(filePath, event.data);
});
ws.addEventListener("close", (event) => {
console.log(`WebSocket 连接已关闭,代码: ${event.code}, 原因: ${event.reason}`);
fs.appendFileSync(filePath, `关闭时间: ${new Date().toLocaleString()}\n`);
});
ws.addEventListener("error", (error) => {
console.error("WebSocket 连接出错:", error);
});
下面两个配置的区别
如果让这个域名 twns.p2ptun.qq.com 🚫_dns_block 或者 🎭_fakeip VPN都不会断开。
{
"dns": {
"rules": [
// { "query_type": [ "A", "AAAA" ], "server": "🎭_fakeip" }
// { "domain": "twns.p2ptun.qq.com", "server": "🎭_fakeip" }
{ "domain": "twns.p2ptun.qq.com", "server": "🚫_dns_block" }
]
}
}
会导致断开的配置
{
"log": { "level": "trace", "disabled": false, "output": "box.log", "timestamp": true },
"experimental": {
"clash_api": { "external_controller": "0.0.0.0:9090", "default_mode": "📜 规则" },
"cache_file": { "enabled": true, "path": "cache.db", "store_fakeip": true, "store_rdrc": true }
},
"dns": {
"strategy": "ipv4_only",
"servers": [
{ "tag": "🏠_local_dns", "address": "h3://223.5.5.5/dns-query", "detour": "📶_不代理" }
]
},
"inbounds": [
{ "tag": "🚇", "type": "tun", "stack": "gvisor", "inet4_address": "172.19.0.1/30", "auto_route": true, "strict_route": false, "endpoint_independent_nat": false, "sniff": true }
],
"route": {
"final": "📶_不代理", "auto_detect_interface": true,
"rules": [
{ "outbound": "🧩_DNS解析", "protocol": "dns" },
{ "outbound": "🧩_DNS解析", "port": 53 },
{ "outbound": "📶_不代理", "ip_is_private": true }
]
},
"outbounds": [
{ "tag": "📶_不代理", "type": "direct" },
{ "tag": "🧩_DNS解析", "type": "dns" }
]
}
会导致断开的配置的日志
可以正常使用的配置
{
"log": { "level": "trace", "disabled": false, "output": "box.log", "timestamp": true },
"experimental": {
"clash_api": { "external_controller": "0.0.0.0:9090", "default_mode": "📜 规则" },
"cache_file": { "enabled": true, "path": "cache.db", "store_fakeip": true, "store_rdrc": true }
},
"dns": {
"strategy": "ipv4_only",
"servers": [
{ "tag": "🏠_local_dns", "address": "h3://223.5.5.5/dns-query", "detour": "📶_不代理" },
{ "tag": "🎭_fakeip", "address": "fakeip" },
{ "tag": "🚫_dns_block", "address": "rcode://success" }
],
"rules": [
// { "query_type": [ "A", "AAAA" ], "server": "🎭_fakeip" }
// { "domain": "twns.p2ptun.qq.com", "server": "🎭_fakeip" }
{ "domain": "twns.p2ptun.qq.com", "server": "🚫_dns_block" }
],
"fakeip": { "enabled": true, "inet4_range": "198.18.0.0/15" }
},
"inbounds": [
{ "tag": "🚇", "type": "tun", "stack": "gvisor", "inet4_address": "172.19.0.1/30", "auto_route": true, "strict_route": false, "endpoint_independent_nat": false, "sniff": true }
],
"route": {
"final": "📶_不代理", "auto_detect_interface": true,
"rules": [
{ "outbound": "🧩_DNS解析", "protocol": "dns" },
{ "outbound": "🧩_DNS解析", "port": 53 },
{ "outbound": "📶_不代理", "ip_is_private": true }
]
},
"outbounds": [
{ "tag": "📶_不代理", "type": "direct" },
{ "tag": "🧩_DNS解析", "type": "dns" }
]
}
可以正常使用的配置的日志 🚫_dns_block
可以正常使用的配置的日志 🎭_fakeip
日志
Settings - View Service Log: 没有崩溃日志。
Service Log 没有内容显示:Empty content,
如果需要提供更多信息,请指导我如何提供“”
支持我们
- [X] 我已经 赞助
完整性要求
- [X] 我保证阅读了文档,了解所有我编写的配置文件项的含义,而不是大量堆砌看似有用的选项或默认值。
- [X] 我保证提供了可以在本地重现该问题的服务器、客户端配置文件与流程,而不是一个脱敏的复杂客户端配置文件。
- [X] 我保证提供了可用于重现我报告的错误的最简配置,而不是依赖远程服务器、TUN、图形界面客户端或者其他闭源软件。
- [X] 我保证提供了完整的配置文件与日志,而不是出于对自身智力的自信而仅提供了部分认为有用的部分。
感谢测试,是否可以再测试 sniff + protocol stun block 能否识别到?
以及网易云也有类似的情况,不知道有没有解决办法。
感谢测试,是否可以再测试 sniff + protocol stun block 能否识别到?
以及网易云也有类似的情况,不知道有没有解决办法。
是否是这样。下面两个配置分别是:
①:dns.rules{ "protocol": ["stun"], "server": "🚫_dns_block" } 有问题
②:①基础上 + inbounds 中的 tun: "sniff_override_destination": true 有问题
日志中好像也没有 sniffed packet protocol: stun
// 这样也试过,也有问题。
{
"route": {
"rules": [
{ "protocol": "stun","outbound":"🚫_拦截" }
]
},
"outbounds": [
{ "tag": "🚫_拦截", "type": "block" }
]
}
配置文件
{
"log": { "level": "trace", "disabled": false, "output": "box.log", "timestamp": true },
"experimental": {
"clash_api": { "external_controller": "0.0.0.0:9090", "default_mode": "📜 规则" },
"cache_file": { "enabled": true, "path": "cache.db", "store_fakeip": true, "store_rdrc": true }
},
"dns": {
"strategy": "ipv4_only",
"servers": [
{ "tag": "🏠_local_dns", "address": "h3://223.5.5.5/dns-query", "detour": "📶_不代理" },
{ "tag": "🚫_dns_block", "address": "rcode://success" }
],
"rules": [
{ "protocol": ["stun"], "server": "🚫_dns_block" }
]
},
"inbounds": [
{ "tag": "🚇", "type": "tun", "stack": "gvisor", "inet4_address": "172.19.0.1/30", "auto_route": true, "strict_route": false, "endpoint_independent_nat": false, "sniff": true }
],
"route": {
"final": "📶_不代理", "auto_detect_interface": true,
"rules": [
{ "outbound": "🧩_DNS解析", "protocol": "dns" },
{ "outbound": "🧩_DNS解析", "port": 53 },
{ "outbound": "📶_不代理", "ip_is_private": true }
]
},
"outbounds": [
{ "tag": "📶_不代理", "type": "direct" },
{ "tag": "🧩_DNS解析", "type": "dns" }
]
}
日志: 测QQ音乐 dns_protocol_stun_block.log
配置文件
{
"log": { "level": "trace", "disabled": false, "output": "box.log", "timestamp": true },
"experimental": {
"clash_api": { "external_controller": "0.0.0.0:9090", "default_mode": "📜 规则" },
"cache_file": { "enabled": true, "path": "cache.db", "store_fakeip": true, "store_rdrc": true }
},
"dns": {
"strategy": "ipv4_only",
"servers": [
{ "tag": "🏠_local_dns", "address": "h3://223.5.5.5/dns-query", "detour": "📶_不代理" },
{ "tag": "🚫_dns_block", "address": "rcode://success" }
],
"rules": [
{ "protocol": ["stun"], "server": "🚫_dns_block" }
]
},
"inbounds": [
{ "tag": "🚇", "type": "tun", "stack": "gvisor", "inet4_address": "172.19.0.1/30", "auto_route": true, "strict_route": false, "endpoint_independent_nat": false,
"sniff": true, // 这个之前的上面的配置就是这样。
"sniff_override_destination": true // 增加了这里
}
],
"route": {
"final": "📶_不代理", "auto_detect_interface": true,
"rules": [
{ "outbound": "🧩_DNS解析", "protocol": "dns" },
{ "outbound": "🧩_DNS解析", "port": 53 },
{ "outbound": "📶_不代理", "ip_is_private": true }
]
},
"outbounds": [
{ "tag": "📶_不代理", "type": "direct" },
{ "tag": "🧩_DNS解析", "type": "dns" }
]
}
然后补充一下,这是Mac上面的QQ音乐,Mac没有问题。(只会有几个UDP连接)
iOS上面目前我观察到每次都是301个。其中有一次出现了两个301。
这个问题确实困扰了我很久,对我而言使用 dns_block 或 fake_ip 算是解决了...
还有一种情况就是:全局代理时(应该)也不会出现问题。如果需要更多测试我很愿意帮忙(我这里也只能帮到这个忙了。)
inbound packet connection to 113.108.28.102:3478
你能提供首个连接到端口 3478 的 UDP 数据包 Wireshark 抓包文件吗?
inbound packet connection to 113.108.28.102:3478
你能提供首个连接到端口 3478 的 UDP 数据包 Wireshark 抓包文件吗?
Wireshark 我之前没有实际使用过。我按照以下步骤操作提供日志和抓包文件。
测试准备:
手机和Mac通过USB连接,Mac运行 rvictl -s 手机UUID。Wireshark 监听网卡 rvi0
Wireshark有一个提示,但是数据能监听到。不知道是否有影响。
这一次测试出现了很多个IP(测试设备不同)(最后断开VPN断开时的IP是 120.41.105.203:43575 )。我看metacubexd的观察:好像前面的IP的连接个数都是刚开始 301 个连接,然后很快变成了1 。
配置文件(也就是最开始的【会导致断开的配置】)
{
"log": { "level": "trace", "disabled": false, "output": "box.log", "timestamp": true },
"experimental": {
"clash_api": { "external_controller": "0.0.0.0:9090", "default_mode": "📜 规则" },
"cache_file": { "enabled": true, "path": "cache.db", "store_fakeip": true, "store_rdrc": true }
},
"dns": {
"strategy": "ipv4_only",
"servers": [
{ "tag": "🏠_local_dns", "address": "h3://223.5.5.5/dns-query", "detour": "📶_不代理" }
]
},
"inbounds": [
{ "tag": "🚇", "type": "tun", "stack": "gvisor", "inet4_address": "172.19.0.1/30", "auto_route": true, "strict_route": false, "endpoint_independent_nat": false, "sniff": true }
],
"route": {
"final": "📶_不代理", "auto_detect_interface": true,
"rules": [
{ "outbound": "🧩_DNS解析", "protocol": "dns" },
{ "outbound": "🧩_DNS解析", "port": 53 },
{ "outbound": "📶_不代理", "ip_is_private": true }
]
},
"outbounds": [
{ "tag": "📶_不代理", "type": "direct" },
{ "tag": "🧩_DNS解析", "type": "dns" }
]
}
sing-box 日志: 测QQ音乐-Wireshark.log
Wireshark 的抓包文件超过25MB了,我上传到了这里: https://github.com/yanhao98/files/releases/tag/sing-box-files
然后好像我看了下这些建立UDP连接的IP,在日志中没有看到是哪个域名的解析结果。
twns.p2ptun.qq.com的解析结果的IP倒是也有进行连接。
{"type":"info","payload":"dns: exchanged twns.p2ptun.qq.com A twns.p2ptun.qq.com. 8 IN A 112.60.24.38"}
{"type":"info","payload":"[4204896304 0ms] inbound/tun[🚇]: inbound packet connection to 112.60.24.38:3478"}
环境与楼主相同,只不过手机是14 plus,用gvisor就会断开,屏蔽了楼主提供的域名也不行,只能缓解而已,改system就没问题了,另外这个问题实在是很久了,从1.7时代应该就有。
环境与楼主相同,只不过手机是14 plus,用gvisor就会断开,屏蔽了楼主提供的域名也不行,只能缓解而已,改system就没问题了,另外这个问题实在是很久了,从1.7时代应该就有。
我用指定域名 fakeip + gvisor 已经用了3天10GB+的流量没有出现问题,我最开始尝试这样解决的时候是发现:我在全局代理的时候不会断开。然后尝试了全部都使用fakeip(也就是{ "query_type": [ "A", "AAAA" ], "server": "🎭_fakeip" })。然后尝试了单独域名 fakeip。你也可以再试试全局代理或者全部使用fakeip呢。
环境与楼主相同,只不过手机是14 plus,用gvisor就会断开,屏蔽了楼主提供的域名也不行,只能缓解而已,改system就没问题了,另外这个问题实在是很久了,从1.7时代应该就有。
我是 ios 17.5.1,也是 qq 音乐。没有发现有域名 twns.p2ptun.qq.com 连接。反而用 gvisor 就会有问题,反复超出内存限制,goroutines 爆表,不断重启。用 system 就没问题了。
This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 5 days
我这里从 1.11.0-beta.2(左右) 开始在qq音乐已经没有这个问题了。