VPN and Internet Censorship Glossary

Equipment on the network that looks inside traffic rather than only at where it is addressed, and decides what to do with it based on what it finds.

DPI is usually described as reading your data. On an encrypted connection it cannot: the payload is ciphertext. What it reads is the shape of the traffic — packet sizes, timing, the unencrypted opening bytes of a handshake, the pattern of who talks first and how much. That is enough to identify a protocol without decrypting a byte of it, which is why a VPN can be blocked while remaining perfectly unreadable. It also explains why obfuscation works by changing that shape rather than by adding more encryption.

See also: Obfuscation · TLS fingerprinting · Active probing

Blocking a site by making the network answer the question "what is this domain's address?" with the wrong answer, or with no answer at all.

The cheapest form of blocking there is, and the easiest to defeat — changing resolver often restores access, which is why people conclude that a block was "just DNS". Two cautions. Changing resolver only helps if the network lets the query reach it; many networks redirect all port 53 traffic to their own resolver regardless of what you configured. And a site blocked by DNS is frequently blocked by IP or SNI as well, so the DNS fix reveals the next layer rather than the open internet.

See also: DNS leak · SNI filtering
Test this yourself →

Blocking an HTTPS connection by reading the site name that the browser sends in the clear at the start of the TLS handshake.

The detail that surprises people: HTTPS encrypts the page, but the opening handshake announces which site you are connecting to in plain text, so that servers hosting many sites know which certificate to present. That field — Server Name Indication — is a per-site block list written into the protocol by accident. Encrypted Client Hello closes it, but it needs support at both ends and is easy for a censor to block wholesale precisely because it is still rare enough to stand out.

See also: Deep packet inspection (DPI) · Domain fronting

Dropping traffic to or from particular addresses, regardless of what the traffic contains.

Blunt, and therefore revealing. Because one address often serves thousands of unrelated sites, IP blocking is the method most likely to take down bystanders, and the collateral damage is how outside observers frequently discover that a block happened at all. For a VPN it is an arms race of pure arithmetic: the provider adds addresses, the censor enumerates and blocks them. Whoever can iterate faster wins that month.

See also: Datacenter IP vs residential IP · Autonomous System Number (ASN)

Identifying the software behind an encrypted connection from the exact way it opens the handshake.

Every TLS client offers its ciphers, extensions and curves in a particular order. That order is a signature of the library, not of the user, and it is sent before encryption begins. A censor does not need to know what you are sending if it can tell that you are not sending it with a browser. This is why serious circumvention tools go to the trouble of imitating a real browser's handshake byte for byte rather than merely encrypting well.

See also: Deep packet inspection (DPI) · Reality (XTLS)

A censor connecting to a server you just used, to see whether it answers like a proxy.

Passive detection asks what your traffic looks like; active probing asks what your server does when a stranger knocks. If the server responds to a malformed request in a way only a particular proxy would, it is identified and blocked, and your traffic never had to give it away. The defence is for the server to be indistinguishable from something ordinary when approached without the right credentials — which is the design goal behind Reality and modern Shadowsocks alike.

See also: Reality (XTLS) · Shadowsocks

Slowing a connection deliberately rather than blocking it, until it is too painful to use.

Increasingly preferred by censors over outright blocking, for a political reason rather than a technical one: a blocked service produces an error message and a news story, while a service that merely never loads produces a user who blames their phone. It is also far harder to measure, since slowness is ambiguous by nature. Treat a service that works everywhere except one network, at one time of day, as a likely throttle rather than a coincidence.

See also: Confirmed blocking vs anomaly

A confirmed block is one where a measurement positively identified censorship; an anomaly is one where something looked wrong but nothing proved why.

This distinction is the difference between a censorship statistic worth quoting and one worth ignoring, and almost every published figure blurs it. A confirmed block means something conclusive was seen, typically a block page. An anomaly means a DNS answer disagreed, or a connection reset, or a certificate did not match — all of which censorship causes, and all of which an ordinary outage also causes. Adding the two together inflates the total, sometimes several-fold. When you see a blocking percentage with no note about which one it counts, assume the larger.

See also: Block page

The page a network substitutes for the site you asked for, telling you it is unavailable.

Valuable out of proportion to its content, because it is the one form of censorship that admits to itself. Measurement projects can match a known block page and record the event as proven rather than suspected. Censors that want deniability have moved away from them in favour of timeouts and resets, which look exactly like a broken network — so the decline of the block page has made censorship harder to count, not rarer.

See also: Confirmed blocking vs anomaly

The combined filtering system operating at China's international network borders.

Not a firewall and not one system: a layered combination of DNS tampering, IP blocking, SNI inspection, TLS fingerprinting, active probing and throttling, applied unevenly across provinces and carriers and changed frequently. Two practical consequences. Reports that a tool "works in China" are observations about one network at one moment, not properties of the tool. And it is the environment most circumvention techniques are designed against, which is why techniques that look excessive elsewhere are standard there.

See also: Active probing · Reality (XTLS) · Obfuscation

Changing what traffic looks like on the wire so that inspection equipment cannot tell what protocol it is.

Commonly described as "extra encryption", which gets the mechanism backwards. Encryption hides content; obfuscation hides identity, and the two are close to independent. WireGuard is strongly encrypted and trivially recognisable — its handshake has a fixed shape a censor can match on sight. Obfuscation adds padding, random junk, or an imitation of some other protocol, none of which makes the traffic more secret, all of which makes it harder to classify. A tool can be excellent at one and useless at the other.

See also: Deep packet inspection (DPI) · AmneziaWG · Pluggable transport

A swappable layer that disguises a tool's traffic, so the disguise can be replaced without changing the tool.

An architectural idea from Tor that turned out to matter more than any particular disguise. Censors adapt in weeks; a system that has to be rewritten each time loses. Separating "transport the data securely" from "look like something else" means a new disguise can ship on its own schedule. When you read that a tool "supports obfs4 and Snowflake", this is the machinery being described.

See also: obfs4 · Snowflake · Obfuscation

A Tor pluggable transport that makes traffic look like nothing at all — no recognisable protocol, and no response to anyone without the right key.

Its design answers active probing rather than passive inspection. An obfs4 bridge does not merely look unusual; it refuses to reveal itself to a connection that cannot prove it already knows the bridge's secret, so scanning for bridges finds silence. The weakness is inherent to that approach: traffic that resembles no known protocol is itself a category, and a censor willing to block everything unrecognised will catch it. That is the reasoning behind the later shift toward imitating real protocols rather than avoiding all of them.

See also: Pluggable transport · Active probing · Reality (XTLS)

A lightweight encrypted proxy, originally written in China to get past the Great Firewall.

Not a VPN, and the difference matters: it proxies the applications configured to use it rather than carrying your whole device's traffic, so anything not pointed at it — often including DNS — continues to travel in the open. It is also not one thing. Early versions were detectable by their lack of any handshake; current ones authenticate to resist probing. "I use Shadowsocks" says little without saying which implementation and which cipher.

See also: Proxy vs VPN · Active probing · V2Ray and Xray

A framework that carries traffic over a choice of protocols and disguises, rather than a single protocol of its own.

The source of endless confusion because the name refers to a platform, not a method. A V2Ray or Xray setup might be VMess over WebSocket behind a CDN, or VLESS with Reality, or a plain Shadowsocks endpoint — configurations with entirely different detection properties. Xray is a fork of V2Ray that now leads on features, Reality among them. When someone says a network blocks V2Ray, ask which transport they were running; the answer usually explains it.

See also: VMess and VLESS · Reality (XTLS) · Shadowsocks

Two transport protocols from the V2Ray family; VLESS is the later, deliberately simpler one.

VMess encrypts and authenticates on its own. VLESS does neither, and that is the point rather than an oversight: it assumes it runs inside TLS, which already provides both, and avoids the second encryption layer whose distinctive shape gave VMess away to traffic analysis. Less work done at the protocol layer leaves fewer fingerprints. VLESS with nothing underneath it, however, is plaintext.

See also: V2Ray and Xray · Reality (XTLS)

A technique that makes a proxy server present the TLS handshake of a genuine third-party website, so inspection sees an ordinary visit to that site.

Earlier approaches imitated a real site; Reality borrows one. A probe that connects without the right key is quietly passed through to the real website it is impersonating and gets a real certificate from it, so probing confirms the cover story rather than breaking it. This defeats both TLS fingerprinting and active probing at once, which is why it became the default recommendation in heavily filtered networks. It is not magic: the cover site must be plausible for you to be visiting, and traffic volume that no ordinary visitor would generate is still a signal.

See also: TLS fingerprinting · Active probing · VMess and VLESS

Hiding the real destination of a request behind a large provider's name, by putting one domain in the visible handshake and another inside the encrypted request.

For several years the strongest circumvention technique available, because blocking it meant blocking a major cloud platform wholesale. It is mostly historical now: the large providers disabled the mismatch between outer and inner names in 2018, having concluded it was a liability. Worth knowing because the idea recurs — Reality is a descendant of the same insight, that the safest disguise is one a censor cannot block without breaking something it needs.

See also: SNI filtering · Reality (XTLS)

An unlisted entry point into a network like Tor, handed out in small numbers so that it cannot simply be added to a block list.

Tor's public relays are published, which makes blocking them clerical work. Bridges exist to be unpublished, and the whole problem becomes distribution: give them out freely and the censor collects them like anyone else; give them out too carefully and the people who need them cannot get them. Every bridge distribution scheme is a compromise between those two failures, which is why obtaining one can feel oddly awkward.

See also: Snowflake · Pluggable transport

A Tor transport that routes through short-lived volunteer browsers using the same technology as video calls.

Its cleverness is economic rather than cryptographic. The relay is an ordinary person's browser tab, running for minutes, with a residential address indistinguishable from any other — so there is no stable list to block, and the traffic is WebRTC, which a censor cannot ban without also banning video calls. The cost is inherited from that design: the connection lasts as long as a stranger's tab stays open.

See also: Bridge · WebRTC leak

A modified WireGuard that adds junk data and configurable header values so its handshake no longer matches WireGuard's signature.

WireGuard's first handshake packet is a fixed size with a fixed first byte — a pattern DPI can match with a single rule, and several countries do. AmneziaWG keeps the cryptography unchanged and alters only the shape: junk packets before the handshake, extra bytes inside it, different header type values. The catch is that both ends must agree on every parameter, and a configuration that is merely wrong rather than invalid will connect happily while carrying the very fingerprint the padding was supposed to hide.

See also: WireGuard · Junk packets (Jc, Jmin, Jmax) · Obfuscation

Meaningless packets AmneziaWG sends before the real handshake, so that the first thing a censor sees is not a handshake.

Jc is how many to send; Jmin and Jmax bound their random sizes. The temptation is to raise Jc for safety, which is the wrong instinct twice over: every junk packet is added latency on every connection, and a burst of uniform random noise before each session is itself a pattern. Values in the low single digits with a wide size range disturb the fingerprint without creating a new one. Both peers must use identical settings.

See also: AmneziaWG · Header magic (S1, S2, H1–H4)

AmneziaWG parameters that pad the handshake packets and replace WireGuard's four fixed message-type values.

S1 and S2 add bytes to the initiation and response packets; H1 to H4 replace the constants 1, 2, 3 and 4 that identify WireGuard message types. Two constraints get missed constantly. H1 to H4 must all differ from each other, or the peers cannot tell message types apart. And S1 + 56 must not equal S2: WireGuard's initiation is 148 bytes and its response 92, the init longer by exactly 56, so that combination pads the two into being the same size as each other — trading one fixed relationship between the handshake packets for another. What makes either mistake dangerous is that the tunnel comes up and passes traffic regardless.

See also: AmneziaWG · Junk packets (Jc, Jmin, Jmax)

A VPN protocol built around a small, fixed set of modern cryptography and about four thousand lines of code.

Its defining choice was to remove options. There is no cipher negotiation, so there is no downgrade attack and no misconfiguration; there is also no way to change anything when one of those choices ages. The same minimalism produces its one real weakness for censored networks — a handshake so consistent that identifying it takes a single rule. Excellent cryptography and poor camouflage are not a contradiction; they are different problems.

See also: AmneziaWG · Handshake · Obfuscation

The long-established open-source VPN protocol, configurable to a fault and able to run over TCP port 443.

Slower than WireGuard and considerably more complex, but still chosen deliberately in two situations. It can be made to resemble ordinary HTTPS traffic on the port HTTPS uses, which matters where anything else is blocked. And it runs on equipment that will never see a WireGuard implementation. Its configurability is genuinely double-edged: the same flexibility that allows the disguise allows a deployment that is meaningfully weaker than its defaults.

See also: WireGuard · Obfuscation

A VPN protocol pairing built into most operating systems, notable for surviving a change of network.

The reason your phone keeps its tunnel when it moves from Wi-Fi to mobile data is usually IKEv2's MOBIKE. Against censorship it fares badly: it uses fixed, well-known UDP ports that are among the first things a filtering network closes, and it has no camouflage of its own. Good default on a free network, poor choice on a hostile one.

See also: WireGuard · OpenVPN

An obsolete VPN protocol whose encryption has been considered broken since the 1990s.

Included here because it is still offered, still configured, and still described in listicles as "fast". It is fast because it is barely doing anything. Its authentication can be reduced to a single DES key and cracked as a service. Treat a provider that still lists PPTP as a feature as a statement about that provider.

See also: OpenVPN · IKEv2/IPsec

The opening exchange in which two parties agree on keys before any protected data is sent.

Worth understanding because it is where nearly all censorship acts. The handshake necessarily happens before encryption is established, so parts of it are visible by construction: the site name in TLS, the packet sizes and message types in WireGuard, the cipher list that fingerprints your client. Blocking a connection at handshake time is cheap and leaves no trace in the logs of the service you were trying to reach.

See also: TLS fingerprinting · SNI filtering · Perfect forward secrecy

The largest packet a link will carry, and the adjustment that keeps tunnelled packets under it.

The cause of the strangest VPN symptom there is: the connection works, small sites load, and then one page hangs forever. A tunnel adds headers, so a packet that just fit now does not; if the message that should report this is filtered — and blocking all ICMP is a common habit — the sender never learns, and large transfers stall in silence. Lowering the MTU or clamping the MSS fixes it. Reach for this before blaming the provider.

Your device asking your ordinary DNS resolver which addresses to visit while connected to a VPN, so that resolver still sees every site you open.

The traffic is encrypted and the questions about it are not. Your ISP cannot read the pages but has a timestamped list of what you looked up, which for most purposes is the same information. It happens through split-tunnel rules, IPv6 resolvers the client ignored, and operating-system features that query every available interface at once and use whichever replies first. Assume nothing and test it.

See also: DNS filtering · IPv6 leak · Split tunneling
Test this yourself →

A browser revealing your real IP address through the API that makes video calls work, regardless of your VPN.

WebRTC needs to know your real addresses to connect two people directly, so it asks for them — and a page can read the answer without permission and without any visible sign. The VPN is not at fault and cannot prevent it: the disclosure happens inside the browser, above the tunnel. Browser settings or an extension fix it; a different VPN does not.

See also: Snowflake
Test this yourself →

IPv6 traffic bypassing a tunnel that only carries IPv4, exposing your real address to any site reachable over IPv6.

Quiet, because everything appears to work. Your network and the site both support IPv6, your VPN does not route it, so the connection goes around the tunnel and arrives with your real address — and nothing anywhere reports an error. A client that handles this either carries IPv6 or disables it outright while connected. One that does neither is leaking by default.

See also: DNS leak · Kill switch
Test this yourself →

A rule that blocks all traffic if the VPN drops, rather than letting it continue unprotected.

Without one, a reconnection is a window of unprotected traffic you will never notice, because the applications simply carry on. Quality varies more than the single checkbox suggests: a firewall-level switch holds even if the client process is killed, while one implemented inside the app does not, and some only engage after the client notices the drop rather than before. Ask which kind, then test it by ending the VPN process rather than by disconnecting politely.

See also: Split tunneling

Sending some applications or destinations through the VPN while the rest use the ordinary connection.

Useful and routinely misconfigured. The common failure is forgetting that DNS is not an application: an app excluded from the tunnel may still resolve names through it, or — far worse — an app inside the tunnel may resolve through the system resolver outside it. Treat any split-tunnel setup as requiring a leak test afterwards, not as a setting you toggle and trust.

See also: DNS leak · Kill switch
Test this yourself →

Using fresh, temporary keys for each session, so recording traffic today and stealing the server's key tomorrow does not decrypt it.

The threat it addresses is patient rather than immediate: an adversary who cannot break your encryption now can store it and wait for the key to be seized, leaked, or eventually computed. Forward secrecy makes that archive worthless, one session at a time. Standard in WireGuard and in modern TLS; its absence in an older configuration is a reason to change the configuration.

See also: Handshake · WireGuard

A provider's claim that it does not retain records able to connect an account to its activity.

A claim, not a property, and the wording is where the substance is. "No activity logs" and "no logs" differ: the first permits connection timestamps and byte counts, which are frequently enough to correlate a user with a session. What distinguishes a meaningful policy is evidence — an independent audit of the running infrastructure rather than of the document, or a court request the provider was unable to answer. Read what is promised, not the heading.

See also: Warrant canary

A regularly renewed statement that no secret legal demand has been received, on the theory that its removal says what the provider may not.

Legally untested nearly everywhere, and weaker in practice than it sounds — a canary that quietly stops being updated is ambiguous between a gag order and an unattended website. Its value is mostly as a signal of intent. If you rely on one, note what date it is supposed to be renewed and actually check.

See also: No-logs policy

Routing through two or more VPN servers so that no single server knows both who you are and what you are doing.

Genuinely useful against one specific threat: a single compromised or compelled server. It does very little against an observer who can watch both ends of the path, and nothing at all against the browser-level tracking that identifies most people. If both hops belong to the same provider under the same jurisdiction, the threat it defends against has not really been divided.

See also: Tor over VPN, and VPN over Tor

Two different orderings of the same two tools, with different consequences.

Tor over VPN — VPN first, then Tor — hides from your ISP that you use Tor and is the arrangement that makes sense in places where using it draws attention; your VPN provider knows you are using Tor, the Tor entry node does not see your address. VPN over Tor is the reverse and is rarely what someone wants: it gives the provider a stable identity for your Tor traffic and breaks Tor's assumptions. If unsure, the first is the one you mean.

See also: Multi-hop · Bridge

The number that identifies where traffic should be delivered on the internet.

Treated as an identity and it is not quite one. Most home connections share an address among many households, most mobile networks share one among thousands, and most addresses change over time. What an address reliably indicates is the network and roughly the region — which is precisely what geographic restrictions act on, and precisely what a VPN changes.

See also: Carrier-grade NAT (CGNAT) · Datacenter IP vs residential IP · Autonomous System Number (ASN)
Test this yourself →

Whether an address belongs to a hosting provider or to a consumer internet connection.

The distinction most blocking now rests on. Addresses are published in ranges by their owners, so anyone can tell that a visitor is arriving from a cloud provider rather than a home connection — and since ordinary customers do not browse from servers, that is a cheap signal for blocking VPNs, scrapers and fraud alike. It is also why a VPN can be working flawlessly and still be refused: nothing about your traffic gave it away, only the address's paperwork.

See also: IP blocking · Autonomous System Number (ASN) · IP address
Test this yourself →

The identifier of a network that routes traffic on its own behalf — an ISP, a hosting company, a large enterprise.

The unit at which the internet is actually blocked and analysed. An address is nearly meaningless alone; the ASN behind it says whether it is a Turkish mobile carrier or a German hosting firm. Censorship also varies by ASN within one country, which is why two people in the same city can disagree entirely about whether a site is blocked, and why measurement data is worth reading per network rather than per country.

See also: Datacenter IP vs residential IP · IP blocking

An ISP placing many customers behind one public address because there are not enough addresses to go around.

Explains two everyday puzzles. It is why you may share a public address with strangers and inherit a block earned by one of them. And it is why incoming connections fail — hosting anything, or connecting directly to your own home network, needs an address that is yours, and behind CGNAT none is. Most mobile networks and a growing share of home connections work this way.

See also: IP address

A proxy relays the traffic of applications that were told to use it; a VPN carries everything the device sends.

The practical difference is what happens to the traffic you forgot about. A browser proxy leaves your other applications, your operating system's own connections and frequently your DNS travelling normally, and none of them will warn you. Proxies also often provide no encryption at all, which is fine for changing an apparent location and useless for privacy. Neither is better; they answer different questions.

See also: Shadowsocks · Smart DNS · DNS leak

A service that alters only the name-resolution step to make a streaming site believe you are elsewhere, without tunnelling your traffic.

Fast, because your video does not travel through anyone else's server, and offering no privacy whatsoever for the same reason: your ISP sees every connection exactly as before, and your real address reaches the site. It is a geography tool, not a security tool, and describing it as "like a VPN but faster" omits the part that matters.

See also: Proxy vs VPN · DNS filtering

Encryption makes traffic unreadable; tunnelling changes the path it takes. A VPN does both, and they solve different problems.

Keeping them apart resolves most confusion about what a VPN can do. Encryption stops your network operator reading the content — but HTTPS already does that for the web. Tunnelling moves your apparent origin, which is what defeats geographic blocks and hides the destination from your ISP. The genuinely new thing a VPN adds over HTTPS is mostly the second. And neither one hides anything from the site you are signed in to.

See also: Obfuscation · Handshake