FakeHTTP使用记录

发表于

使用方法

参考：https://github.com/MikeWang000000/FakeHTTP/releases

1
./fakehttp -e baidu.com -e sougou.com -a -z -d

疑问

FakeHTTP 在 TCP 流量上做了“混淆”，为什么不会影响真实的服务端正常通信。这个关键点在于 它只动了 TCP 握手阶段的一部分内容，而不是整个应用层的数据。
这个关键点在于 它只动了 TCP 握手阶段的一部分内容，而不是整个应用层的数据。

实际服务过程抓包如下：

🌐 原理分析

  1. TCP 连接建立是三次握手

    • 客户端发 SYN
    • 服务端回 SYN+ACK
    • 客户端再发 ACK
      握手完成后，TCP 才进入“已连接”状态。

  2. FakeHTTP 并不是把真实数据都变成 HTTP

    • 它在握手阶段，用 伪造的 HTTP 报文包裹这些 TCP 报文。
    • 例如：原本要发 ACK，它可能在包体里加点 HTTP-like header，让 DPI 觉得这是一个 HTTP 请求。

  3. 服务端实际看到的还是标准 TCP 握手

    • 因为这些“伪装内容”并不会送到真实应用层去解释。
    • 服务端的 TCP 协议栈只关心握手报文的 TCP 头部字段（SYN/ACK/序号/窗口等），对里面伪装的 HTTP header 内容不关心。
    • 换句话说，FakeHTTP 只在传输途中迷惑 DPI，但最终到达服务端内核 TCP 协议栈时，依然是一个合法的 TCP 握手。

  4. 握手完成后，FakeHTTP 不再干预

    • 后续的数据传输（HTTP、HTTPS、SSH、FTP …）都不再被 FakeHTTP 修改。
    • 因此真实服务接收到的内容就是原样的业务数据，不会被混淆破坏。

🔑 为什么不会影响真实服务

  • DPI 只看中途：FakeHTTP 插入的“HTTP 外壳”主要是让防火墙/DPI 误判，而不是给服务端解析的。
  • 内核只看 TCP 头：服务端操作系统只认 TCP 头的字段，不会去解析伪装的数据。
  • 应用层完全不感知：握手完成后，应用层服务（比如 Nginx、SSH 守护进程）看到的就是正常的 TCP 连接，没有任何异常。

📌 类比一下

这有点像寄快递时在外包装盒上贴了“水果”的标签（伪装成 HTTP），让中途的检查员以为是水果；
但里面装的东西（真实 TCP 握手/数据）是没有被动的，最终收件人（真实服务端）拆开后还是原本的内容。