Proposal: advanced SNI-spoofing techniques (TCP-seq injection, fake ClientHello, TLS record fragment, TTL tricks) beyond the existing fragment

[minor-way]

Background

Xray-core already ships the fragment setting in the freedom outbound (packets: "tlshello"), which has been invaluable for bypassing SNI-based DPI filters. Thank you to the maintainers for that feature — it saved a lot of users for a long time.

However, in the past months Iran's national DPI has adapted. The classic TCP-segment fragmentation that fragment produces is now reassembled by the DPI before inspection, so the SNI becomes visible again and blocked SNIs (e.g. *.cloudfront.net, *.cloudflare.com, various others) get the connection RST'd or silently stalled after Server Hello.

Field observation (Iran, 2026-04 — reproduced on MCI, Irancell, MobinNet (mobile) and Shatel, MKH (fixed-line)):

• curl direct: TLS handshake to *.cloudfront.net RSTs after Server Hello.

• Xray-core with:

  "fragment": {
    "packets": "tlshello",
    "length": "100-200",
    "interval": "10-20"
  }

  Same RST / stall behavior. DPI is no longer fooled by TCP-layer fragmentation.

• Dedicated external spoofing tools (patterniha/SNI-Spoofing, aleskxyz/SNI-Spoofing-Go, therealaleph/sni-spoofing-rust) successfully bypass the block using techniques fragment does not implement.

What the external tools do that fragment does not

1. TCP sequence injection (decoy ClientHello with out-of-window seq_num) — the most effective technique against current Iranian DPI. After the TCP 3-way handshake completes, a fully-valid fake ClientHello is injected as a raw packet carrying an allowed SNI, but with seq_num = syn_seq + 1 - len(payload), which falls outside the server's receive window. The DPI reads the fake SNI and whitelists the flow; the server's TCP stack silently discards the packet (out-of-window); the real ClientHello follows immediately on the correct sequence and is processed normally. Requires raw-socket / kernel-hook packet injection (WinDivert on Windows, NFQUEUE on Linux, pf divert on BSD/macOS).
2. Fake / decoy ClientHello injection (socket-layer, no seq manipulation) — a first ClientHello is sent with a benign SNI (e.g. letsencrypt.org). The DPI consumes it; the real ClientHello follows on the same TCP stream. Weaker than technique number 1 because some DPIs parse both ClientHellos and still match on the second, but works in pure userspace without raw sockets.
3. TLS record-layer fragmentation — splitting the SNI extension across multiple TLS records instead of multiple TCP segments. Bypasses DPIs that reassemble at the TCP layer but not at the TLS record layer.
4. TTL / HOP-limit tricks — sending a decoy ClientHello with TTL low enough to die between DPI and origin, then sending the real one. Requires per-packet TTL control (raw socket or IP_TTL setsockopt).
5. Disorder / out-of-order segments — deliberately sending TCP segments with reversed sequence so the DPI's reassembly differs from the server's.

Why this belongs in Xray-core

• Every affected user currently has to run a second process (sni-spoof tool) next to Xray, which doubles setup friction, hurts mobile battery life, and makes router deployments painful.
• The fragment setting already established the precedent that anti-censorship primitives belong in-core.
• A unified config is far easier to maintain than chaining two TCP proxies on 127.0.0.1.

Proposed config schema

Extend the existing fragment (or add a sibling sniSpoof block) on streamSettings.sockopt so it's available to all outbounds (VLESS, VMess, Trojan, etc.), not only freedom:

{
  "streamSettings": {
    "sockopt": {
      "sniSpoof": {
        "mode": "seqInject",
        "fakeSni": "letsencrypt.org",
        "ttl": 4,
        "recordSize": "30-60",
        "delay": "5-15"
      }
    }
  }
}

Field reference:

Field	Applies to mode	Description
mode	all	"seqInject" | "fakeHello" | "tlsRecord" | "ttl" | "disorder"
fakeSni	seqInject, fakeHello, ttl	SNI to use in the decoy ClientHello
ttl	ttl	IP TTL for the decoy packet
recordSize	tlsRecord	Size range (bytes) for each TLS record fragment
delay	seqInject, fakeHello, ttl	Milliseconds between decoy and real ClientHello

mode is a single value for now; combinations can be added later. Defaults chosen so the block is a drop-in replacement for the existing freedom.fragment use case.

Scope proposal (incremental PRs)

PR	Scope	Difficulty	Platform deps
1	TLS record-layer fragmentation	Low	None
2	Fake ClientHello (decoy SNI, socket-layer)	Medium	None
3	Generalize to streamSettings.sockopt (all outbounds)	Medium	None
4	TTL-based spoofing	High	Needs IP_TTL setsockopt / raw socket permission
5	Disorder (out-of-order TCP segments)	High	Platform-dependent
6	TCP sequence injection (decoy ClientHello with wrong seq_num)	High	WinDivert (Windows) / NFQUEUE (Linux) / pf divert (BSD/macOS) — build-tag gated

PRs 1–3 are pure userspace Go and should land without elevated privileges. PRs 4–6 require raw-socket / kernel-hook packet injection and should be gated behind a build tag so the default binary stays dependency-free. Among these, PR number 6 is the most impactful against current Iranian DPI, based on field testing of external tools implementing this exact technique.

References

• Working external tools using these techniques:
  • https://github.com/patterniha/SNI-Spoofing
  • https://github.com/aleskxyz/SNI-Spoofing-Go
  • https://github.com/therealaleph/sni-spoofing-rust
• Prior art in-tree: proxy/freedom/freedom.go fragment implementation.

Ask

1. Would the maintainers accept PRs in the order above?
2. Preference on config layout: extend fragment (add a mode field) vs. a new sibling sniSpoof block?
3. Are TTL / disorder techniques (which need elevated privileges on some OSes) acceptable behind a build tag, or should they stay out of core?

Happy to submit PR number 1 (TLS record fragmentation) first as a proof of concept if there's interest. A reference implementation of PR number 6 (TCP sequence injection) already exists as a standalone Windows proxy using WinDivert and could be ported to an Xray transport wrapper.

[RPRX]

#5964 (comment)

[minor-way]

Thanks — adding TTL to finalmask/header/custom would cover technique number 4 in the proposal (TTL decoy) and is a clean, lightweight addition. I'd welcome a PR.

Two notes from field testing on MCI / Irancell / Shatel in 2026-04:

• Simple TCP fragmentation (fragment: tlshello) no longer works — the DPI reassembles segments before inspection. This suggests the DPI is state-aware and likely applies TTL decrement correctly, so I'm not confident TTL-alone will survive (but it's very worth testing once the PR lands).
• The technique that does currently work in the field is TCP sequence injection (PR number 6 in the scope table) — decoy ClientHello with out-of-window seq_num. That's independent of TTL and requires raw-socket / NFQUEUE plumbing. I'd still like to pursue it as a separate track.

Happy to run A/B tests once a TTL-capable nightly is available.