可配置的 Rust HTTP MITM 代理，支持 TLS、HTTP/2 和 TCP 指纹伪造。
一个使用 Rust、tokio 和 btls 构建的 HTTP MITM 代理。
本项目已完全重写，以利用 btls（BoringSSL）实现高级 TLS 指纹识别能力。TLS 指纹识别层（JA3/JA4）现已完全可伪造——密码套件、曲线、签名算法、ALPN、记录大小限制、证书压缩、GREASE、扩展排列/顺序、OCSP 装订、证书透明度（SCT）、会话票据、ALPS 以及加密客户端问候（ECH，通过 DoH 实时解析，并带有 GREASE 回退）均由 YAML 配置文件驱动。HTTP/2 指纹识别（Akamai）以及 HTTP/1.1 头部排序/重写也完全可配置。TCP（L4）指纹识别同样已上线：上游连接的 SYN 数据包在 NFQUEUE 中被重写（TTL、窗口大小、MSS、窗口缩放、DF 标志、时间戳、精确的 TCP 选项顺序、按域名标记），并自动管理 iptables。
MITM（中间人） — 透明 HTTPS 拦截。它使用 rcgen 动态签发并签名证书，并通过 moka 缓存证书以提升性能。
BoringSSL 集成 — 使用 btls 和 tokio-btls 处理 TLS 握手和 MITM 拦截。
TLS 指纹伪造（JA3/JA4）—— 完整实现。 上游 TLS 连接完全由通过 -c / --config <path> 传入的 YAML 配置文件构建（格式参见 config.yaml）：
brotli、zlib、zstd），支持真实解压。TLS.md。上游优先的 ALPN 协商 — 代理在完成浏览器侧 TLS 握手之前，先与上游服务器建立并协商 TLS。随后使用上游服务器选择的 ALPN 来配置客户端侧 TLS 接受器，防止浏览器选择上游连接不支持的协议。
HTTP/2 指纹伪造（Akamai） — 通过 YAML 配置文件完全可配置的 HTTP/2 指纹识别：
END_STREAM 放置位置。HTTP/1.1 头部伪造 — 针对纯 HTTP/1.1 上游连接（当 ALPN 未协商 h2 时），可配置头部顺序和内容，与 HTTP/2 使用相同的覆盖/移除语义。
TCP 指纹伪造（L4）—— 完整实现。 出站上游连接通过 Linux NFQUEUE 在数据包级别进行指纹识别（src/tcp_fingerprint/）：
Accept 判定，因此队列不会停滞。SO_MARK 的路由到按域名的 TCP 配置文件，自动管理 iptables（插入到 zapret/nfqws 等工具之上，去重，在 Ctrl+C 关闭时移除），并带有 --queue-bypass 安全机制。TCP.md 以及 config.yaml 中的 tcp 块。上游 HTTP 代理支持 — 可通过 CONNECT 方法经上游 HTTP 代理转发连接。
按域名配置文件路由 — 传入 -d / --domain <path>，附带域名模式到部分配置文件覆盖的映射（参见 domain.yaml）。每个连接按 SNI 匹配（精确 → *.root → *.label.* → label.* → 基础配置文件），并使用其自身的 TCP/TLS/HTTP2/HTTP1/上游设置提供服务，在启动时预先构建一次。只需指定与基础配置文件不同的字段；其余全部继承。
异步 — 基于 tokio 构建，实现高性能、非阻塞的异步 I/O。
cap_net_admin,cap_net_raw=+eip（用于 SO_MARK、NFQUEUE 绑定和自动 iptables；若没有，请在 tcp 块中设置 "auto_iptables": false 并手动应用 mangle 规则 — 参见 TCP.md）该代理使用 tracing，通过 RUST_LOG 进行按模块过滤。
示例：
RUST_LOG='H2=error' cargo run --release -- -c profile.yaml
RUST_LOG='TCP=debug,H2=error,TLS=warn' cargo run --release -- -c profile.yaml
RUST_LOG='CA=info,TLS=warn,H2=error' cargo run --release -- -c profile.yaml
支持的标签与代码中使用的模块名称相同：TCP、HTTP、H1、H2、TLS、CA、ECH、CFG、IPT、NFQUEUE、Runtime。
日志行默认包含时间戳，因此调试会话更容易关联。
git clone https://github.com/3Radiance/mitm-proxy-ja3-ja4.git
cd mitm-proxy-ja3-ja4
cargo build --release
所有设置——端口、上游代理和 CA 文件路径——都位于通过 -c / --config <path> 传入的 YAML 配置中。没有 --port / --upstream 命令行标志。
config:
port: 9090
upstream_proxy: "127.0.0.1:10808"
cert: "/path/to/ca.crt"
key: "/path/to/ca.key"
要不在上游代理的情况下运行，请设置 upstream_proxy: null。
cargo run --release -- --config profile.yaml
# or
cargo run --release -- -c profile.yaml
首次运行时，如果 cert/key 尚不存在，代理将在配置的路径下生成 CA 文件：
ca.crt — 根 CA 证书。你必须将其导入 Firefox/你的浏览器并信任它，以识别网站。ca.key — CA 的私钥。cargo run --release -- -c profile.yaml -d domain.yaml
domain.yaml 将域名模式映射到部分覆盖层——仅包含与基础配置文件不同的字段：
"browserleaks.com":
config:
upstream_proxy: null
tls:
enable_ech: false
"*.google.com":
tls:
enable_ech: true
"tls.peet.ws":
tcp:
mark: "0x11"
ttl: 100
window_size: 64130
mss: 1400
window_scale: 7
dont_fragment: true
timestamp: false
tcp_options_order:
- mss
- sack_perm
- wscale
- nop
"mail.google.*":
tls:
curves:
- X25519
- P-256
每个连接的匹配顺序（按 SNI，不区分大小写）：精确匹配 → *.root → *.label.* → label.* → 基础配置。缺失的键（或除 upstream_proxy 之外的任何位置为 null）表示“从基础配置继承”，而 "upstream_proxy": null 则显式强制该域名使用直连。TCP 字段（包括 mark）以相同方式继承基础配置——"mark": null 会取消该域名的 mark。注意：如果基础配置设置了 upstream_proxy，则完全不会应用 SO_MARK，并且 TCP 层会被绕过（参见 TCP.md）。
src/main.rs：CLI 入口点，使用 clap 解析 -c / --config <path>。YAML 配置包含代理端口、上游代理、CA 路径、TLS 指纹配置文件和 HTTP/2 指纹配置文件。src/config.rs：YAML 配置模型以及所有指纹层的解析器。处理 TLS 设置、ECH/DoH 选项、HTTP/2 SETTINGS、流优先级、头部排序、HTTP 头部覆盖、伪头部排序以及其他配置文件特定选项。
src/domain.rs：按域名的配置文件覆盖（-d / --domain）。部分覆盖在启动时一次性深度合并到基础配置之上；每个连接的查找是廉价的 Arc 克隆，无需重新分配。
src/proxy/tcp.rs：TCP 连接处理、初始 HTTP CONNECT 解析、上游 TCP 连接建立（当配置文件设置了 mark 时，通过 SO_MARK 标记套接字）、SNI 提取、按域名配置文件路由（SNI 匹配，回退到基础配置）、上游 TLS 协商，以及将生成的 TLS 连接桥接到客户端。
src/proxy/http.rs：使用 httparse 进行最小化的 HTTP/1.x 请求/响应解析，包括 CONNECT 方法验证以及提取目标 host:port。
src/tls_fingerprint/cert.rs：使用 rcgen 和 btls::x509 即时生成证书，由本地 CA 签名并缓存在 moka 缓存中。
src/tls_fingerprint/tls.rs：btls / tokio-btls TLS 接受器和连接器配置、上游 TLS 协商、客户端 TLS 握手处理以及 ALPN 协商。
src/tls_fingerprint/helpers.rs：用于密码套件、曲线、签名算法、ALPN、扩展顺序/排列、记录大小限制、证书压缩、GREASE、OCSP 装订、SCT、会话票据和 ALPS 的各个 TLS 指纹配置辅助函数。
src/tls_fingerprint/compression.rs：Brotli、zlib 和 zstd 的证书压缩实现。
src/tls_fingerprint/ech.rs：通过 DoH 实时解析 ECH 配置（HTTPS/SVCB 记录查找，对 DoH 请求本身复用已配置的 TLS/HTTP2 指纹），当主机未发布配置时回退到 GREASE。
src/h2_fingerprint/h2.rs：HTTP/2 连接入口点和连接级请求处理。协调客户端 HTTP/2 连接与已配置的上游 HTTP/2 连接。
src/h2_fingerprint/request.rs：传入 HTTP/2 请求处理、请求构造、伪头部排序、HTTP 头部操作、上游流创建以及请求/响应转发协调。
src/h2_fingerprint/request_body.rs：流式 HTTP/2 请求体转发、流控制处理、END_STREAM 放置以及请求尾部。
src/h2_fingerprint/response.rs：HTTP/2 响应转发、响应体流式传输、流控制处理、END_STREAM 处理以及响应尾部。
src/h2_fingerprint/upstream.rs：根据活动指纹配置文件创建和配置上游 HTTP/2 客户端连接。
src/h1_fingerprint/h1.rs：HTTP/1.1 上游请求处理（当 ALPN 未协商 h2 时使用），包括可配置的头部顺序和内容，基于 hyper 构建。src/tcp_fingerprint/syn.rs：用于 SYN 数据包的 NFQUEUE 消费者——窗口/TTL/DF 重写、根据 tcp_options_order 重建 TCP 选项、校验和重新计算、裁决时清除 fwmark。src/tcp_fingerprint/tcp.rs：用于已建立流的 NFQUEUE 消费者——仅处理 TTL/DF（IPv6 跳数限制），默认接受所有内容。src/tcp_fingerprint/iptables.rs：自动 mangle 规则管理——在第三方规则之上顶部插入、去重、关闭时清理。该项目划分为相互独立的层：
src/
├── config.rs
├── domain.rs
├── main.rs
├── logging.rs
│
├── proxy/
│ ├── mod.rs
│ ├── tcp.rs
│ └── http.rs
│
├── tcp_fingerprint/
│ ├── mod.rs
│ ├── syn.rs
│ ├── tcp.rs
│ └── iptables.rs
│
├── tls_fingerprint/
│ ├── mod.rs
│ ├── cert.rs
│ ├── compression.rs
│ ├── ech.rs
│ ├── helpers.rs
│ └── tls.rs
│
├── h2_fingerprint/
│ ├── mod.rs
│ ├── h2.rs
│ ├── request.rs
│ ├── request_body.rs
│ ├── response.rs
│ └── upstream.rs
│
└── h1_fingerprint/
├── mod.rs
└── h1.rs
proxy 层处理原始 TCP 和 HTTP CONNECT 流量，tcp_fingerprint 层在数据包进入网络之前于 NFQUEUE 中重写出站数据包，tls_fingerprint 层处理 TLS 拦截、TLS 指纹识别和 ECH 解析，h2_fingerprint 层处理 HTTP/2 指纹识别和流级流量，h1_fingerprint 层则为未协商 h2 的上游连接处理 HTTP/1.1 头部指纹识别。这种分离使传输层、L4、TLS 以及各协议指纹识别逻辑保持独立，同时允许各层在单次代理连接期间协同工作。
MIT