【新进展】300块求解决一个代理问题

[复制链接]
查看: 8294   回复: 7
发表于 2023-11-26 16:10:53 | 显示全部楼层 |阅读模式
感谢某猫猫头大佬。定位到问题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端口

然后我尝试用
  1. curl -v --proxy http://username:password@代理服务器A的IP:8989 ip.p3terx.com
复制代码
这样的命令去验证是否成了。

最后当然正常返回了代理服务器的IP地址,到现在为止,一切都很正常!

接着因为我的吃灰小鸡大部分都是线路不咋地的。所以直连肯定拉跨。我就用openclash写了一条规则   - DST-PORT,8989,Proxy ,这样所有往8989的连接都会走Proxy这个服务器中转了。事实也是如此,从连接观看,每个都是成功的走上了代理。

然后就是神奇的地方了,现在我如果重新输入这个命令,我想到的情况是,应该会正常通过openclash上的代理去连吧?
  1. curl -v --proxy http://username:password@代理服务器A的IP:8989 ip.p3terx.com
复制代码
很不幸,现在无法连接了。 然后我就想着难道沪日上的V2出问题了?
于是我将日志调整为了debug级别,发现在输入curl命令的瞬间。确实有一条指向了代理服务器A的连接,但是去代理服务器A的日志查看。完全没有任何入站连接。
  1.    "log":{        "access": "/var/log/v2ray/access.log",        "errors": "/var/log/v2ray/errors.log",        "loglevel": "debug"    },
复制代码




此时我怀疑是不是沪日这个机子的网络有问题。连接不上代理服务器A 。我就直接在沪日专线这个v2机上输入了相同的命令。
答案是一切正常,成功回显了代理服务器IP,这是代理服务器的log,成功接受到了入站连接。


此时我陷入了迷惑之中,可接下来发生的事情在我的认知中只能用玄学来解释

因为我每个代理服务器都是有80 443端口上的web服务器的。我就想着直接curl自己的机子,看看nginx日志能不能看到啥异常。
于是我在本地输入了这样一条命令,
  1. 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
回复

使用道具 举报

 楼主| 发表于 2023-11-26 16:11:32 | 显示全部楼层
我是楼下。我不会啊
回复 支持 反对

使用道具 举报

 楼主| 发表于 2023-11-26 16:12:24 | 显示全部楼层
捞一捞
回复 支持 反对

使用道具 举报

 楼主| 发表于 2023-11-26 16:13:03 | 显示全部楼层
大家都是mjj  楼下大佬会帮你完美解决的
回复 支持 反对

使用道具 举报

 楼主| 发表于 2023-11-26 16:13:55 | 显示全部楼层
感觉是你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地址) - - [09/Feb/2022:09:48:03 +0800] "GET / HTTP/1.1" 200 5107 "-" "curl/7.55.1"

这一步你可以开关下clash看看区别。
回复 支持 反对

使用道具 举报

 楼主| 发表于 2023-11-26 16:14:26 | 显示全部楼层
好长,下次看:lol
回复 支持 反对

使用道具 举报

 楼主| 发表于 2023-11-26 16:14:46 | 显示全部楼层
自己小鸡一般不是走ssh么,不需要搭其他代理么。建议你直接在小鸡上下载
回复 支持 反对

使用道具 举报

发表于 2023-11-26 16:15:23 | 显示全部楼层
帖子说了啊。。就是开了clash之后出现的问题。
不开clash一切正常。但是速度慢。
开了clash之后 clash也正确的将请求转发到了指定的节点了

这个节点也收到了请求代理服务器的日志

但就是代理服务器没得反应。如果直接在节点服务器上请求代理服务器是可以的。通过v2来请求就不行了。所以我现在在翻v2的文档看看是不是有啥限制。不过翻了半天也没翻到啥信息

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
回复 支持 反对

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则