|
感谢某猫猫头大佬。定位到问题SniffingObject,并有了解决方案, 目前不知是bug还是特性。
------------
继续折腾了2个小时,发现一个可疑的地方。
我依然是输入curl -v --proxy http://username:password@154.31.*.*:8989 google.com
这下面的日志是clash上连接的沪日节点的。第一条没看明白,入站请求怎么是来自http代理IP的8989端口的,然后后面的就是最后怎么去请求了谷歌的8989端口了。无论curl "谁"最后v2都是去请求 "谁:8989"了,怪不得除了自己在8989上搭了http代理的服务器都无法访问。
这是什么原理,有办法解决吗!
2022/02/09 11:37:30 [Info] [690003155] proxy/vmess/inbound: received request for tcp:154.31.*.*:8989
2022/02/09 11:37:30 [Info] [690003155] app/dispatcher: sniffed domain: google.com
2022/02/09 11:37:30 [Info] [690003155] app/dispatcher: default route for tcp:google.com:8989
2022/02/09 11:37:30 [Info] [690003155] proxy/freedom: opening connection to tcp:google.com:8989
2022/02/09 11:37:30 [Info] [690003155] transport/internet/tcp: dialing TCP to tcp:google.com:8989
-----------------------------
在这上面研究了7个小时了。我以放弃
首先是这样,需求是某个网站下载东西,单IP限速。我就拿我的一堆小鸡用Tinyproxy这个软件,搭了一堆http代理去下载。https://tinyproxy.github.io/
以下称为代理服务器A,B等,所有的代理服务器设置的http代理端口跟验证都是同样的8989端口
然后我尝试用- curl -v --proxy http://username:password@代理服务器A的IP:8989 ip.p3terx.com
复制代码 这样的命令去验证是否成了。
最后当然正常返回了代理服务器的IP地址,到现在为止,一切都很正常!
接着因为我的吃灰小鸡大部分都是线路不咋地的。所以直连肯定拉跨。我就用openclash写了一条规则 - DST-PORT,8989,Proxy ,这样所有往8989的连接都会走Proxy这个服务器中转了。事实也是如此,从连接观看,每个都是成功的走上了代理。
然后就是神奇的地方了,现在我如果重新输入这个命令,我想到的情况是,应该会正常通过openclash上的代理去连吧?- curl -v --proxy http://username:password@代理服务器A的IP:8989 ip.p3terx.com
复制代码 很不幸,现在无法连接了。 然后我就想着难道沪日上的V2出问题了?
于是我将日志调整为了debug级别,发现在输入curl命令的瞬间。确实有一条指向了代理服务器A的连接,但是去代理服务器A的日志查看。完全没有任何入站连接。- "log":{ "access": "/var/log/v2ray/access.log", "errors": "/var/log/v2ray/errors.log", "loglevel": "debug" },
复制代码
此时我怀疑是不是沪日这个机子的网络有问题。连接不上代理服务器A 。我就直接在沪日专线这个v2机上输入了相同的命令。
答案是一切正常,成功回显了代理服务器IP,这是代理服务器的log,成功接受到了入站连接。
此时我陷入了迷惑之中,可接下来发生的事情在我的认知中只能用玄学来解释
因为我每个代理服务器都是有80 443端口上的web服务器的。我就想着直接curl自己的机子,看看nginx日志能不能看到啥异常。
于是我在本地输入了这样一条命令,- curl -v --proxy http://username:password@代理服务器A的IP:8989 https://代理服务器B.com
复制代码
接着我去代理服务器B的nginx访问日志查看,惊呆了
有一条这样的访问日志
119.28.*.*(访客IP居然是我访问的web服务器,也就是代理服务器B自己的IP地址) - - [09/Feb/2022:09:48:03 +0800] "GET / HTTP/1.1" 200 5107 "-" "curl/7.55.1"
然后我又试了把目标地址从https://代理服务器B.com改为https://代理服务器A.com
154.31.*.*(现在正常显示为--proxy中填的8989那个代理服务器A的IP) - - [09/Feb/2022:01:49:25 +0000] "GET / HTTP/1.1" 200 917 "-" "curl/7.55.1"
如果将以上所有命令代理服务器A换成B ,最后的效果完全一样,比如用代理服务器B curl 代理服务器A的web,访客IP一样是A自己,但是访问除了代理服务器A,B以外的机子。都连不上
curl一样卡在proxy-connection这一步,但是v2的日志一切正常?彻底凌乱
|
本帖子中包含更多资源
您需要 登录 才可以下载或查看,没有帐号?立即注册
x
|