Active probing: how they check you

Everyone more or less understands passive inspection. But that the censor can, on its own behalf, knock on your port and check you — that's a surprise to many. Let's break down why it does this, what exactly it compares in the response, and why honest self-steal beats probing where ordinary Reality starts to sweat.

This material is about engineering your own infrastructure and is educational in nature. Complying with the laws of your own jurisdiction is on you.

What active probing is

Passive inspection watches the traffic that already flows past. Active probing is fundamentally different: the censor initiates a connection to your server itself and observes the reaction. It suspects a connection — instead of blocking right away, a second or two later it sends its own request to you and compares the response with a reference of "how the site you're pretending to be should behave."

The logic is murderously simple. If the address claims to be an ordinary HTTPS site, then it should answer a bare request like a site: serve a page, a redirect, an error, a TLS alert — something recognizably web-server-like. But if a proxy is sitting there waiting for a secret handshake, it will give itself away on a "wrong" request: hang silently, drop the connection in a strange way, or answer with something a normal site never produces. This discrepancy between "claimed" and "actually answers" is what probing catches.

Why this is more dangerous than passive analysis

Passive statistics can be blurred: wrap on a transport, tune lengths and timings, dissolve into the background. Probing can't be fooled this way, because it's not about the shape of the traffic, but about the fact: does a real service live at the address, or an impostor?

And here a fundamental fork of any stealth protocol appears. Your node must distinguish its own client from a stranger's request — otherwise anyone could connect. So somewhere there's an "friend/foe" check. The question is what the node does with the foe:

• The naive blunder: the foe is told "didn't get it, goodbye" — with a drop, a protocol error, silence. That's exactly the response probing is waiting for. You gave yourself away.
• The right approach: the foe gets exactly what a real site would answer, the one you're disguising as. Probing knocks — and gets a normal web response. It can't tell the difference.

The whole Reality construction is built around the second point. A client without a valid key (the short shortId, the pair's public key) doesn't get a rebuff — the node transparently proxies its request to the real donor and returns the donor's real response to the client. From the outside it looks as if the claimed site really lives at that address. Probing catches air.

Where ordinary Reality still gets exposed

Reality is good, but the classic scheme has a subtle gap. Usually the donor is someone else's large site: you set serverName: www.microsoft.com, and during probing the node proxies to the real Microsoft. It works. But under deep analysis a mismatch surfaces that a real site could never have:

• The client claims SNI www.microsoft.com.
• But it's reaching your IP.
• And in DNS www.microsoft.com resolves to completely different addresses, not yours.

For an honest site, name, IP, and content are consistent: www.microsoft.com really lives on Microsoft's infrastructure. Your node has someone else's name and your own IP. Smart inspection can cross-reference this: "someone on this IP is answering on Microsoft's behalf, even though Microsoft isn't hosted here." It's not instant death, but an extra mismatch — and mismatches are what a decision to block is built from.

The self-steal idea: steal your own site

Self-steal closes precisely this gap. The idea is to make the donor your own site rather than someone else's:

• serverNames = your domain, whose A record honestly points to your node.
• And the donor (target/dest), the one the node proxies foreign requests to during probing, is a decoy site brought up right here, on this same node (a local web server).

Now everything lines up perfectly. The SNI is your domain. The IP is yours. The content at that address is a real working site (the decoy). Probing knocks on https://your-domain — and lands on a real, live page that is physically hosted exactly where DNS points. No "name from one, IP from another" mismatch. Open that address in a browser and you'll see an ordinary site. And the censor, during an active ping-through, will see exactly the same thing: an ordinary web server on an ordinary domain.

The key detail people often miss: the decoy site must be plausible. An empty "It works" page is also a signal: a real domain with "nothing" behind it is suspicious. A landing page, a blog, anything alive — that's what you need. The more ordinary the site looks, the more boring the node is to probe.

What disguise doesn't solve

Honestly about the limits. Self-steal beats probing and the "name vs IP" mismatch, but it doesn't cancel the other two dimensions of inspection:

• The handshake fingerprint still has to be browser-like (fp), or you get exposed before it ever comes to probing.
• Self-steal doesn't blur the statistics of the stream — that's the job of the transport (XHTTP/gRPC on top).

And one more: the IP itself may already be poisoned regardless of how perfectly the disguise is configured. Then it gets cut on approach, and no self-steal helps — cured by rotating the address or by a CDN.

So self-steal isn't a "silver bullet," it's the closing of one specific, most inconvenient door. Probing is the only layer where you can't "blur," you can only honestly be a real site. Self-steal is what makes you real.

Next — in the practice: how to bring up a decoy site on a local socket, how to bind it to the Reality inbound via PROXY protocol, and how to verify that probing sees a normal site. Step by step in "Resistance to active probing: setup."