关于修改 HTTP 请求头问题

[lycos]

通过手动修改 HTTP 请求头的方式可以轻易骗过服务器，达到所谓的“伪造”客户端 IP 地址的目的，这招并非对于所有的网站有效（这取决于服务器获取 ClientIP 的方式）。
问题，如何避免访问网站的服务器端获取到本地真实 ip 呢？

[Havee]

有些服务上了 cdn ，来路就基本都是那些 cdn 节点了
这个时候读 http head 省事

[Shieffan]

挂代理、 VPN



或者你修改本机 IP ，然后修改从本机 IP 到目标主机的所有路由设备的路由信息，以便它们能给你寻路，嗯，上帝模式。

[lycos]

@mcfog 服务端不是我控制的

[lycos]

@Shieffan 修改了本机 ip 不可行的

[gamexg]

tcp 协议设计之初就考虑到会有楼主这种伪装 ip 的攻击，设计时就封堵的差不多了。
后期一些容易操作的有问题的设计（例如源端路由）也都被纠正了。

另外一些就是运营商才能做到的了。

[Strikeactor]

乖乖挂代理吧，这事你不是运营商就别想了

[jin5354]

各种代理和 VPN 就是专门做这个的。憋寻思别的了

[lycos]

@jin5354 恩恩 这个问题问的有点白痴了。。 基本是不可能做到的

[lycos]

@Strikeactor 我当时是抱着等待高手的出现 看看高手有何高见的 。。现在看来是基本不可能了

[TheCure]

我来替 lz 总结一下

我是 lz
我的问题是白痴
你们回到不出我的问题,你们都不是高手

哈哈

[lycos]

@callofmx haha.... 大家回答的都很专业 只是我不专业..

[just1]

REMOTE_ADDR 是无法伪造的
当使用了 cdn ， REMOTE_ADDR 是 cdn 的 ip 。
但是 cdn 一般会传回一个客户的真实 ip 在 header 里。
比如 cf:HTTP_CF_CONNECTING_IP 就是 cdn 接受到的 remote_addr(也就是客户的真实 ip)。
所以隐藏是不太可能的。
但可以这样:穿透 cdn 找到源站 ip(虽然不容易，却也不是没办法)， hosts 指向。在每次请求头加入"HTTP_CF_CONNECTING_IP"，当然如果对方限制了仅 cdnip 可访问那就没办法了。
但是，这是根据程序逻辑来的，有的网站只获取 xff 并不校验，那修改 xff 就够了，同理 clientip 也是这样。

[Cloudee]

可以认为是不可能的

简单理解的话，就是服务器总是要知道你的 IP 来发回复的信息的，所以这个用于发送返回信息的 IP 服务器肯定有办法知道，如果你骗过这个的话，服务器的回复也回复不到你这里了

而因为 TCP 握手是要交互几次的，因此也不存在你把请求丢过去不管返回的情况

[mornlight]

楼主你可以逆向思维一下，如果可以仅在客户端伪造来源 ip 的话，那防火墙的 ip 过滤规则还有什么用？

按目前的协议设计，想要用假 ip 又正常通信，是不可能的。

所谓的改请求头的方式，只是针对非匿名代理或者 CDN 这种（会自动在 HTTP 头里标明请求的源 ip ）。很多网站后端取 ip 时会优先拿请求头里的源 ip 。

[mengzhuo]

@mornlight
@Cloudee

各种 sock_proxy 、 http_proxy 不就是改 IP 源么？

[Cloudee]

@mengzhuo 那是代理服务器做了中转。比如网站 B 和代理服务器 A ，你连 A ， A 连 B ，对于你来说你只跟 A 交互，对于 B 来说， A 才是自己的客户。
并不是你的数据包直接用 A 的 IP 发过去了，而你你把数据包发给 A ， A 把数据包原样用自己的 IP 发给 B 了。这个时候 B 回复是回复给 A 的，并不直接回复给你。

[lycos]

@Cloudee 所以这个过程是服务端既获取到 A 的 ip ， 又识别了数据包头的源 ip

[jasontse]

客户端 A: 你好我是客户端 B 。
服务器 A: 欢迎你，客户端 B 。
客户端 B: 莫名其妙，谁找我?
客户端 A: 尼玛! 服务器 A 不理我(其实招呼打到客户端 B 去了)。。。。

[mengzhuo]

@Cloudee

对啊，不就是这么个意思吗？

[Cloudee]

@mengzhuo 但是你要有可用的代理，并且代理是知道你的 ip 的，因此你还要代理不通过 http 头泄露你的真实 ip