【新进展】300块求解决一个代理问题
感谢某猫猫头大佬。定位到问题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 proxy/vmess/inbound: received request for tcp:154.31.*.*:8989
2022/02/09 11:37:30 app/dispatcher: sniffed domain: google.com
2022/02/09 11:37:30 app/dispatcher: default route for tcp:google.com:8989
2022/02/09 11:37:30 proxy/freedom: opening connection to tcp:google.com:8989
2022/02/09 11:37:30 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地址) - - "GET / HTTP/1.1" 200 5107 "-" "curl/7.55.1"
然后我又试了把目标地址从https://代理服务器B.com改为https://代理服务器A.com
154.31.*.*(现在正常显示为--proxy中填的8989那个代理服务器A的IP) - - "GET / HTTP/1.1" 200 917 "-" "curl/7.55.1"
如果将以上所有命令代理服务器A换成B ,最后的效果完全一样，比如用代理服务器B curl 代理服务器A的web，访客IP一样是A自己，但是访问除了代理服务器A,B以外的机子。都连不上
curl一样卡在proxy-connection这一步，但是v2的日志一切正常？彻底凌乱
我是楼下。我不会啊 捞一捞 大家都是mjj楼下大佬会帮你完美解决的 感觉是你clash Proxy路由的事
因为我每个代理服务器都是有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地址) - - "GET / HTTP/1.1" 200 5107 "-" "curl/7.55.1"
这一步你可以开关下clash看看区别。 好长，下次看:lol 自己小鸡一般不是走ssh么，不需要搭其他代理么。建议你直接在小鸡上下载 帖子说了啊。。就是开了clash之后出现的问题。
不开clash一切正常。但是速度慢。
开了clash之后 clash也正确的将请求转发到了指定的节点了
这个节点也收到了请求代理服务器的日志
但就是代理服务器没得反应。如果直接在节点服务器上请求代理服务器是可以的。通过v2来请求就不行了。所以我现在在翻v2的文档看看是不是有啥限制。不过翻了半天也没翻到啥信息
页:
[1]