Replies: 7 comments 1 reply
-
|
感谢大佬这些经验分享，本人目前处在从 |
Beta Was this translation helpful? Give feedback.
-
|
说得挺详细的，不错。 |
Beta Was this translation helpful? Give feedback.
-
|
大佬可否远程帮我设置一下，我的一直报错，按照你的截图设置了，也不行，电脑小白一个，很多实在不懂啊 |
Beta Was this translation helpful? Give feedback.
-
你可以开启debug日志保存在文件中，然后根据报错内容依次排查，或者把报错的日志发上来看看 |
Beta Was this translation helpful? Give feedback.
-
|
-----【自动回复】邮件已收到，将尽快阅读
|
Beta Was this translation helpful? Give feedback.
-
|
我也是小白，看了很有收获，但按照这番操作一遍后，还是会出现如下报错，不知道什么原因： |
Beta Was this translation helpful? Give feedback.
-
|
-----【自动回复】邮件已收到，将尽快阅读
|
Beta Was this translation helpful? Give feedback.
-
一直以来，我在Windows电脑上浏览自由世界使用的就是v2rayN，感谢@2dust等一众大佬的无私奉献让我们得以开阔视野！
起初作为一个小白（现在也是，只是稍微对网路知识有点了解），都是拿来就用或者看别人教程使用，但也不求甚解，基本能用，但时不时有些问题，特别是tun模式（这也是我最看重的功能）有时会启动不成功，需要反复重启几次，或者成功后网络连接质量不稳定，特别是singbox内核更新到1.9.0以上后更突出，前几天我v2rayN6.45版更新singbox1.9.3内核后网络连接质量非常不稳定，yt开始能达到2万，但过一会就降为几百kps，即使重启有时也没有改善，排除节点质量问题后，我判定应该是软件设置问题，然后去singbox官网去恶补了一下相关知识，通过调整设置后网络稳定流畅了，然后v2rayN又更新了新的预发行版，优化了tun模式，我试用了一下，感觉比原来的模式更好，各个core更相容，xray的协议使用不受singbox的影响，比如gRPC传输模式使用注入singbox时只支持gun，改用现在的方式xray可以使用完整的协议。有鉴于与我有相同问题的朋友不少，在此将我的使用经验和设置方法共享与大家，供参考。
再次声明，本人非专业人士不懂代码，理解错误或不到位在所难免，请大佬们指正。
我的使用环境：
操作系统：Windows11专业工作站版（系统更新到最新，chrome和edge浏览器，系统自带杀毒无第三方杀毒或安全软件）
节点：自建节点，xray的vless协议，通过cdn
v2rayN的使用方式：开启tun，由singbox前置dns解析和路由，代理流量通过xray发出，设置方法基于这种模式进行
首先简单介绍一下v2rayN的流量处理流程（tun功能优化6.47版以上，实际使用建议更新到6.49及以上）
dns解析阶段：本地dns查询流量==>tun==>singbox，嗅探出dns协议，走“dns_out”,由相关进程处理dns查询，经过路由匹配判断，如果走直连则由进程向dns配置里tag为“local”的服务器如223.5.5.5发起查询，由于它的出站类型为“direct”，因此查询直接发出，得到结果后返回给客户端，如果路由匹配判断此域名需要走代理解析，向tag为“remote”的服务器如8.8.8.8发出查询请求，由于它的出站类型为“proxy”，因此流量进入tag为“proxy”的outbound，它采用socks协议，10808端口，本机的xray进程同样采用socks协议监听10808端口，因此查询流量进入xray，xray则根据配置的代理协议向远程服务器发起连接，得到结果后返回客户端。
普通连接阶段：客户端得到目标地址后发起连接请求，请求流量==>tun==>singbox，嗅探出连接协议，根据策略的设置不同，路由判断走直连还是代理，如果是直连则由进程直接发起连接，如果是代理，则通过socks向tag为“proxy”的outbound流出进入到xray，xray通过嗅探，根据策略设置的不同，路由判断直连还是代理（基本上是代理，singbox已经先分流了），如果是代理则直接向远程服务器发起连接，如果是直连则建立目标IP地址与客户端的连接，完成整个连接。
v2rayN的设置要点
v2rayN设置的地方其实并不多，实现上述流程，有几个地方需要注意：
singbox和xray对dns和路由的策略有些不同，所以重点在这些方面进行调整
1、v2rayN设置
在core基础设置里将开启流量探测打开并勾选前三项，RouteOnly建议勾选，由于singbox和xray采用的是转发模式，因此服务器应保持实际core类型，比如采用vless就要选xray，建议在服务器的设置里留空，在参数设置选与协议对应的core类型，一定要与服务器实际使用的保持一致。
更新：经讨论发现tun模式的开启依赖于srs文件，由于各种原因此srs一次下载成功率不高，当前解决办法是开启规则集的缓存，然后只要srs文件成功下载一次被缓存后以后就能正常开启tun（但应该不绝对，可能还有其它因素），还有这个设置有可能会更改，因为规则集缓存不是开启tun的必要条件，以后自己留意一下变化
另外注意：singbox的mux和xray的mux不兼容，除非你清楚怎么使用，否则不要启用，建议按图中设置
2、dns配置
v2rayN在每种类型的dns配置里都有相应的默认设置，要注意的是采用这种工作模式的话目前只有tun模式和v2ray的dns配置有效，singbox的http/socks的dns配置似乎没用上，默认配置基本上就可以了，要注意的是如果你想减少dns泄露，可将final改为remote，在rules里将remote提在local的前面，同时你想明确某些域名解析走local，比如自己的域名，将它列在这里，因为singbox的dns路由是在这里进行的，默认的dns设置只能满足基本需求，如果你有特殊要求，应在这里修改，而v2ray的dns解析会根据策略匹配路由规则，所以可以在路由规则部分进行设置，总之明白这一点后你可以自己折腾。
3、路由策略配置
首先是策略的选择，由于singbox和xray的路由策略和规则有些不同，在v2rayN的路由配置界面里有相应的选项，在这里要注意：singbox的策略选择留空或者根据需要进行IP解析，区别在于如果留空则singbox的入站将不进行解析IP进行路由，只根据域名进行路由，速度更快，但没那么精确，需要路由规则里补充，如果你不太清楚，建议选择解析，xray的路由策略建议选AsIs，重点！这里尽量不要选其它两项，这是因为流量首先进入singbox就会进行路由选择，它决定了流量的走向，xray就没必要再次判断路由了，选AsIs就让xray只根据域名路由，而且singbox发过来的IP连接也会根据IP策略进行路由匹配，不但速度更快而且与singbox更相适应，如果你选了另两个，特别是IPOndemand，不但多出额外的解析时间，而且如果xray的规则判断需要走直连，则它会向本地的dns服务器发出查询请求，这样又回到singbox了，如果路由规则配置不当，可能实际流向不符预期，浪费时间还存在潜在的隐患。
从这里可以看出来，要更好的相容性就尽量采用singbox的规则集，xray可以使用简单的路由即可，但因为不使用tun则系统退回到xray，这时xray的路由规则起作用了，所以自己明白是怎么回事就知道怎样设置了。
4、路由规则配置
默认的路由规则基本上就可以了，不过如果你有特殊需求，要注意规则的顺序，自定义的规则比如自己的域名或者已知的包括VPS域名等必须直连的，就把它提到最前，因为不用tun模式xray需要在这里根据域名进行路由和解析，至于其它的根据需要设置即可。
5、操作系统相关
首先一定要保证系统的干净和完整，干净就是尽量用原生系统，隔一段时间利用sfc等检查系统文件是否有损坏，驱动程序也保持更新，尽量用原生的杀毒软件，不建议用3xx等国内的系统，包括浏览器等都不要用，操作系统不要用魔改版或者精简版。
目前我的v2rayN经过一趟梳理后运行很不错，tun模式建立很顺利，网络连接质量也稳定流畅，另外由于各个软件都在更新，保持对应协议版本一致性也很重要，新老协议不匹配也是问题产生的重要因素。
希望以上的使用经验对你有用，错误之处请指正。
=========================以下更新v2rayN工作时通过debug日志了解系统工作流程，自查自纠===================
想了一下 ，上面描述的第5点我觉得反而是影响v2rayN正常工作的最大因素，因为v2rayN工作在单台电脑上，而Windows操作系统本身作为通用平台，兼容的软件实在是太多，因此稳定性也是比较欠缺的，每一个人电脑装的软件也是形形色色，其中也包括恶意软件等，还有系统工作久了本身已经不稳了等等，另外还有一个重要因素：单台电脑往往也是属于局域网设备，局域网的网络环境也至关重要。
有鉴于此，我觉得出现问题自查自纠非常重要，但像我等这样不懂代码没法通过分析代码来发现bug和完善代码，我们能做的就是先尽量自己查找原因，实在找不到原因，也能够比较清晰的反映问题给@2dust大佬们分析排查，这也可以节省大佬们的宝贵时间。
v2rayN的debug日志非常详细，只要花时间很多问题可以自己找到，至少可以发现大概问题卡在哪里，在这里，我结合我上述配置运行时的debug日志自己进行了分析整理，添加了一些自己的理解，如有不对，请大佬们指出！
特别说明，以下log顺序是我整理了的，去除了一些重复和不相干的内容，实际可能是乱的，你可以通过时间和【】里的ID号串起来
1、xray和singbox的启动
在双core模式下xray和singbox是各自启动的，而且log文件也是分别存储的，singbox的日志以sbox开头加上日期，xray的日志以Verror开头加上日期，我以下贴出来的log是合并了的，但也能区别出来
xray启动log：
2024/06/28 17:17:18 [Debug] app/log: Logger started
2024/06/28 17:17:18 [Info] app/dns: DNS: created UDP client initialized for 223.5.5.5:53 //初始化dns服务器，就是dns配置的内容，这里我只列一个出来//
2024/06/28 17:17:18 [Debug] app/router: MphDomainMatcher is enabled for 5 domain rule(s) //加载域名规则，就是路由配置里面的内容，也只列一个，后面相似的条目都只列一个，以节约版面//
//前面第3点dns配置里也提到xray路由规则问题，这里也可以看得出来//
2024/06/28 17:17:18 [Debug] app/proxyman/inbound: creating stream worker on 127.0.0.1:10888 //xray的入站端口//
2024/06/28 17:17:18 [Info] transport/internet/tcp: listening TCP on 127.0.0.1:10888 // 监听端口//
2024/06/28 17:17:18 [Info] transport/internet/tcp: listening TCP on 127.0.0.1:10893 //xray的自由门监听端口，singbox启动完成前它会接收请求数据，所以它如果接到请求，就会解析自身节点域名IP地址，下面的log可以看见//
2024/06/28 17:17:18 [Warning] core: Xray 1.8.16 started //xray启动完成//
singbox启动log：
+0800 2024-06-28 17:17:19 INFO router: updated default interface WLAN, index 24
+0800 2024-06-28 17:17:19 INFO clash-api: restful api listening at 127.0.0.1:10894
+0800 2024-06-28 17:17:20 INFO inbound/tun[tun-in]: started at singbox_tun
+0800 2024-06-28 17:17:20 INFO [75018264 0ms] inbound/tun[tun-in]: inbound packet connection from 172.19.0.1:55093 //这就是xray发过来的dns域名解析请求包//
+0800 2024-06-28 17:17:20 INFO [75018264 0ms] inbound/tun[tun-in]: inbound packet connection to 172.19.0.2:53 //向53端口查询//
+0800 2024-06-28 17:17:20 DEBUG [75018264 0ms] router: sniffed packet protocol: dns //嗅探出dns协议//
+0800 2024-06-28 17:17:20 DEBUG [75018264 0ms] router: match[0] protocol=dns => dns_out //应用dns路由规则//
+0800 2024-06-28 17:17:20 DEBUG dns: exchange VPS域名. IN A //查询VPS域名//
+0800 2024-06-28 17:17:20 DEBUG dns: match[0] domain=VPS域名 => local_local //匹配查询规则，这里可以看见查询VPS域名使用的服务器，这个服务器必须直连而且能够连通，否则VPS域名解析就会失败，如果你的xraylog里出现找不到主机之类的错误，就是因为这里没有解析到VPS地址//
//
+0800 2024-06-26 17:00:56 ERROR dns: exchange failed for VPS域名. IN A: context deadline exceeded //出现这个错误你后面的工作都没意义，必须先解决这个问题，而且后面会出现大量的其它dns解析失败的信息//
//
+0800 2024-06-28 17:17:20 INFO outbound/direct[direct]: outbound packet connection to 223.5.5.5:53 //向dns服务器发起连接//
+0800 2024-06-28 17:17:20 DEBUG dns: exchanged VPS域名 NOERROR 15
+0800 2024-06-28 17:17:20 INFO dns: exchanged VPS域名 A VPS域名. 15 IN A VPS的IP地址
+0800 2024-06-28 17:17:20 INFO dns: exchanged VPS域名 A VPS域名. 15 IN A VPS的IP地址 //最终解析出VPS地址//
//上面几段log信息非常重要，如果你的网络不通，可搜索类似信息，最终必须找到上面的信息，否则后面工作没法进行//
+0800 2024-06-28 17:17:20 INFO [101960756 0ms] inbound/tun[tun-in]: inbound packet connection from 172.19.0.1:54083 //另一个连接请求//
+0800 2024-06-28 17:17:20 INFO [101960756 0ms] inbound/tun[tun-in]: inbound packet connection to 172.19.0.2:53 //是dns查询包，所以向53端口连接 //
+0800 2024-06-28 17:17:20 DEBUG [101960756 0ms] router: sniffed packet protocol: dns //以下流程一样，最终判断是走代理//
+0800 2024-06-28 17:17:20 DEBUG [101960756 0ms] router: match[0] protocol=dns => dns_out
+0800 2024-06-28 17:17:20 DEBUG dns: exchange lh3.googleusercontent.com. IN A
+0800 2024-06-28 17:17:20 DEBUG dns: match[2] rule_set=geosite-geolocation-!cn => remote
+0800 2024-06-28 17:17:20 INFO outbound/socks[proxy]: outbound packet connection to 8.8.8.8:53
+0800 2024-06-28 17:17:20 INFO sing-box started (1.466s) //singbox启动完成，这里可以看见它比xray慢得多，估计因为tun的关系，如果没有这一个提示，应该tun模式会启动不成功，猜测可能跟前面VPS域名解析有关系，VPS域名解析成功后整个网络才会通畅，如果不通畅可能会关闭tun，这是猜测，可以自己验证一下//
+0800 2024-06-28 17:17:21 DEBUG dns: exchange lh3.googleusercontent.com. IN A
+0800 2024-06-28 17:17:21 DEBUG dns: match[2] rule_set=geosite-geolocation-!cn => remote //singbox将包发向远程，就是发给xray//
2024/06/28 17:17:20 [Info] [3157167029] proxy/socks: client UDP connection from udp:127.0.0.1:54084 //xray接收到上面的包//
2024/06/28 17:17:20 [Debug] [3157167029] proxy/socks: send packet to udp:8.8.8.8:53 with 43 bytes
2024/06/28 17:17:20 [Debug] [3157167029] transport/internet/udp: dispatch request to: udp:8.8.8.8:53
2024/06/28 17:17:20 [Info] transport/internet/udp: establishing new connection for udp:8.8.8.8:53
2024/06/28 17:17:20 [Info] [3157167029] app/dispatcher: taking detour [proxy] for [udp:8.8.8.8:53] //路由选择为代理//
2024/06/28 17:17:20 [Info] [3157167029] transport/internet/grpc: creating connection to tcp:VPS域名:443 //向远程服务器建立连接//
2024/06/28 17:17:20 [Debug] transport/internet/grpc: using gRPC multi mode service name:
VPS域名stream name:TunMulti2024/06/28 17:17:21 [Debug] [3157167029] proxy/socks: writing back UDP response with 88 bytes //得到解析结果//
以上为代理的dns查询过程，可以看见如果之前VPS域名没有解析出IP，这里是无法向外连接成功的，后面的所有连接都会失败
以上为v2rayN启动各组件的工作大致流程，篇幅所限不再叙述其它的，工作流程我在开篇时大概讲过，这里更直观清晰，通过理解整个流程对于我们排查故障很有帮助。
再次强调一点，电脑本身干净稳定至关重要，你安装的一些比较特别的软件，特别是网络密切相关的，记得将它的进程在路由规则里加入直连，否则后果未知，自行排查。
忘了提醒，如果tun模式启动不了，可以改一下监听端口试试，我的截图里就是改过的，因为默认监听端口在我家里的网络环境下启动tun有问题，改端口就解决了
Beta Was this translation helpful? Give feedback.
All reactions