URnetwork
•••

Protocols12 分钟阅读HTML ↗

Protocols

Extenders

Everyday encryption, usable on any network.

Everyday encryption should stay usable no matter what network you are on. HTTPS, your messaging apps and your email already encrypt; this page compares the protocols that keep that working on a restrictive Wi-Fi, a mobile carrier, a hotel, a school or a censored national network. All are held to the same five goals, and extenders are the one that needs nothing set up.

No extra dependencies In every app and the SDK Forwards bytes it cannot read

Reviewed Oct 2026 min readView as markdown ↗

What an accessibility protocol is for

Every protocol here is held to the same five goals; the table scores all five at once.

Everyday encryption, on any network: five goals Top: your encrypted session, drawn as the extenders motif (the apps' ring-around-a-dot icon, elaborated: a filled blue dot, you and your encrypted session, inside a ring of six relay nodes, the extenders, with three strokes linking the ring inward), meets a network that interferes (a restrictive Wi-Fi, a mobile carrier, a hotel or airport, a school, a censored national network), and an accessibility protocol, drawn as a magenta conduit through the wall, carries it through unread to the open internet, still encrypted. Below, five goal cards every protocol on the page is judged against. Reach the open internet: the internet you already use, HTTPS, messaging, email, any destination, both directions, not a curated subset; falls short as a whitelist of sites or the web only. Keep working when a network interferes: blocked, filtered or throttled, the session still gets through, and still works the day after the network notices it; falls short when the network learns its fingerprint or its address. Work out of the box: no server to rent, no config to paste, nothing to install, on by default with nothing to get wrong; falls short when you need a server, a config or a friend. Trust in the path: the hop forwards what it cannot read, encryption runs through it rather than to it, and it learns only what it must; falls short when the hop can read what it carries. Fast enough to live on: few hops, little overhead, no deliberate delay, so video and calls are normal use; falls short when video stutters and calls drop. Each goal card carries the ring-and-dot as its bullet. Caption: a protocol can meet one goal by giving up another; the comparison table scores every protocol against all five at once. These are goals, not scores. Everyday encryption, on any network What an accessibility protocol is for: five goals every protocol on this page is judged against. You your encrypted session A NETWORK THAT INTERFERES restrictive Wi‑Fi · mobile carrier · hotel or airport · school · censored national network Open internet still encrypted an accessibility protocol carries it through, unread GOAL 1 · REACH Reach the open internet The internet you already use: HTTPS, messaging, email, any destination, both directions, not a curated subset. FALLS SHORT WHEN a whitelist of sites, or the web only. GOAL 2 · KEEP WORKING Keep working when a network interferes Blocked, filtered or throttled, the session still gets through, and still works the day after the network notices it. FALLS SHORT WHEN the network learns its fingerprint, or its address. GOAL 3 · NO SETUP Work out of the box No server to rent, no config to paste, nothing to install. On by default, with nothing to get wrong. FALLS SHORT WHEN you need a server, a config, or a friend. GOAL 4 · PRIVACY Trust in the path The hop forwards what it cannot read. Encryption runs through it, not to it, and it learns only what it must. FALLS SHORT WHEN the hop can read what it carries. GOAL 5 · SPEED Fast enough to live on Few hops, little overhead, no deliberate delay: video and calls are normal use, not a stretch goal. FALLS SHORT WHEN video stutters and calls drop. A protocol can meet one goal by giving up another: resilience bought with setup, privacy bought with speed. The table on this page scores every protocol against all five at once. Goals, not scores. Terms follow How URnetwork works; the per-protocol notes carry the evidence behind each cell of the table.
Your encrypted session meets a network that interferes; an accessibility protocol carries it through, unread, to the open internet. Five goals, no scores: reach the open internet, keep working when a network interferes, work out of the box, trust in the path, and stay fast enough to live on.

Out of the box

An extender is a volunteer-run forwarding hop on an independent address — the first leg of the path. It passes your already-encrypted session on to the platform without terminating it, so it carries bytes it cannot read; as your first hop it sees the address you connect from, but not your activity. It is on by default in every app and the SDK.

Direct first

The apps try the normal, direct routes before anything else — nothing is in the way until a network interferes.

Then an extender

If the direct routes are blocked, the apps fall back to extenders on their own, over believable ports (TCP 443, QUIC on 443, a DNS-shaped carrier) until one gets through.

Still encrypted

The extender forwards the sealed session to the platform; it reads nothing, and the exit is a separate residential member.

"No extra dependencies" is literal: nothing to install, no server to rent, no config to paste, no account on a third-party service. Anyone can run an extender, and the SDK's provider role runs the extender role by default.

This is reachability, not anonymity. The extender leg adds no encryption of its own — the seal is the session between you and the platform — and it is no promise against every censor; it is a way to keep the encrypted internet you already use working when a network tries to get in the way.

The extender is a hop, not a cryptographic layer: as your first hop it sees your IP, but your activity stays sealed inside the transport wrapper it forwards without reading. Trust in the path means no one on it can read your traffic — not that no one can see you connect.

The comparison

The columns are protocols, including the two the URnetwork apps speak; the rows are the five goals above, as concrete features. Every cell is explained in the notes that follow.

meets the goal partly, or with conditions —does not 1footnote
Protocol comparison: features by protocol
Feature URnetwork speaks these Other protocols
Feature Extenders nothing beyond the app VLESS + REALITYa server you run or rent Shadowsocksa server, or an Outline key WireGuarda server or VPN provider Snowflakethe Tor client TorTor Browser or Orbot
Reach the open internetGets an encrypted connection out where plain VPNs are blocked Yes Yes Partly —No Yes Yes
Keep working when a network interferesFalls over to another path on its own, rather than one fixed route Yes Partly1 —No —No Yes Yes
Work out of the boxNo server to run or rent, no account, nothing to install Yes —No —No2 —No Yes Yes
Trust in the pathThe first hop forwards a session it cannot read Yes3 —No —No —No Yes Yes
Fast enough to live onStreaming-class, not just reachable Yes Yes Yes Yes Partly Partly

Columns under “URnetwork speaks these” are the protocols the apps and SDK carry; Extenders is the one that needs nothing beyond the app. ● meets the goal, ◐ partly or with conditions, — does not.

  1. VLESS+REALITY+Vision on 443 began stalling under some Russian home-ISP connection-count shaping from late 2025; multiplexed or non-443 setups fared better.
  2. Shadowsocks is out-of-the-box only through a managed service such as Outline, which hands you a key; raw Shadowsocks needs a server you run.
  3. As your first hop, the extender sees the IP you connect from — but not your activity, which stays sealed inside the transport wrapper it forwards without reading. Reachability, not anonymity.

Protocol notes

One card per column, in column order: what it needs to run, where it wins, and where extenders win.

Extenders

Needs: nothing beyond the app

A volunteer-run first hop on an independent address that forwards your encrypted session to the platform without reading it. On by default in every app and the SDK; the provider role runs one by default.

Where extenders win

  • Nothing to install, rent, configure or sign up for
  • Many carriers (TCP 443, QUIC, a DNS-shaped transport) with automatic failover
  • Forwards bytes it cannot read; the exit is a separate residential member

Where extenders fall short

  • Your first hop sees your IP, not your activity — reachability, not anonymity
  • The directory of extenders is discoverable, so addresses can be harvested and blocked by IP
  • Camouflage raises the cost of traffic classification, not of blocking a known address

VLESS + REALITY

Needs: a server you run or rent

A TLS proxy whose REALITY mode borrows a real site's live TLS 1.3 handshake, so a prober sees that real site. The flagship of the modern self-host ecosystem. URnetwork speaks it: it ships in the apps in the next release.

Where it wins

  • Looks like a genuine visit to a real site
  • Resists active probing by design
  • The protocol the circumvention community builds on

Where extenders win

  • Extenders need no server; VLESS needs one you run or rent
  • Many carriers with automatic failover, not one route
  • The first hop can't read the session; a VLESS server terminates it

Shadowsocks / SS2022

Needs: a server, or an Outline key

The ubiquitous lightweight proxy and the engine inside Outline; SS2022 is its modern authenticated refresh. The most widely deployed self-host protocol.

Where it wins

  • Everywhere, simple, and fast
  • Outline turns it into a one-key consumer app
  • An authenticated 2022 mode

Where extenders win

  • Nothing to set up and no key to be handed
  • Rides TLS, QUIC or DNS rather than looking fully random
  • Falls over between carriers on its own

WireGuard

Needs: a server or VPN provider

The modern VPN substrate: small, fast, and in the kernel. The core of most consumer VPNs. A tunnel, not a circumvention protocol.

Where it wins

  • Very fast and battery-light
  • In every major VPN app
  • Audited, minimal design

Where extenders win

  • A plain WireGuard tunnel is trivially fingerprinted and blocked; extenders blend into ordinary traffic
  • Keeps working across carriers
  • No server to run

Snowflake

Needs: the Tor client

Tor's volunteer WebRTC bridge, and the protocol closest to extenders: thousands of short-lived volunteer relays carry a session they cannot read. A measured survivor of 2025's shutdowns.

Where it wins

  • A huge, churning volunteer supply
  • The session survives a relay vanishing
  • Carries Tor's unlinkability

Where extenders win

  • Works without WebRTC/UDP, over TCP 443 and a DNS-shaped carrier
  • In the app, with no separate Tor client
  • Streaming-class speed

Tor

Needs: Tor Browser or Orbot

The reference onion network: three volunteer relays, no one of which sees both who you are and where you are going. The benchmark censors are measured against.

Where it wins

  • The strongest unlinkability here
  • Thousands of volunteer relays
  • The most studied, most trusted design

Where extenders win

  • Fast enough for video and everyday use
  • No separate browser to run
  • Reaches blocked networks without hand-picking bridges

How extenders work

The first hop is more than one relay you hope stays up. Here is the machinery behind it — how a first hop is found, what each party on the path can and cannot see, and how one network serves two roles at once.

Part 1 · Discovery

Finding a first hop

Extenders announce themselves with operator-signed records — a public key, the addresses they answer on, the carriers they speak (TLS on 443, QUIC, and a DNS-shaped transport), and roughly where they sit. A client learns these three ways at once: verifiable DNS records that work from a cold start, a live feed it can sample and subscribe to, and a peer-to-peer gossip mesh that passes records host to host instead of from one server. The client keeps its own copy of the directory and always tries a direct connection first, reaching for an extender carrier only when the direct path is in the way.

Records are spread across many hosts, but they are signed and switched on by the operator — decentralized reach anchored to a trust root, not an operator-less network.
Three ways in, at once
Verifiable DNS recordswork from a cold start
A live feedsample it, subscribe to it
Peer-to-peer gossiprecords pass host to host, not from one server
On your device
Operator-signedYour local directoryeach record: a public key, its addresses and carriers, roughly where it sits
On every connect
Try direct firstnothing is in the way until a network interferes
Then an extender carrierTLS 443 · QUIC · DNS-shaped, from the directory
Three sources feed one local directory of operator-signed records. On every connect the client tries a direct path first and reaches for an extender carrier only when the direct path is in the way.
Part 2 · Trust in the path

Who sees what

Between you and the site there are four parties: the extender that is your first hop, the operator that matches you to an exit, the provider that is your exit, and the destination itself. Each sees only its own slice. Your first hop sees the address you connect from and a sealed session it cannot read — it forwards ciphertext toward the platform and nothing else. Your exit sees where your traffic is going, but never the address you came from; your source address is simply never on that leg of the wire. No single party sees both who you are and what you do.

The seal itself is the encrypted session between you and the site — the extender adds no cryptography of its own. (A stronger seal that also hides destinations from your exit is available, and ships off by default.)

Who sees what: five parties on the path, each seeing only its own slice A left-to-right path: you, then the extender that is your first hop (green), then the operator, then the provider that is your exit (blue), then the destination. One sealed session, drawn as a tube with a padlock, runs from you to the site straight through every hop. You see your own identity and activity. The extender sees your IP and a sealed session it cannot read; it forwards ciphertext and nothing else. The operator sees enough to match you to an exit. The provider sees the destination but never your IP: your address is never on its leg of the wire. The destination sees traffic arriving from your exit. No single party sees both who you are and what you do. SEALED END TO END · THE ENCRYPTED SESSION BETWEEN YOU AND THE SITE your addressis on this leg forwards ciphertextand nothing else your address isnever on this leg YouExtenderOperatorProviderDestination your device your first hop the platform your exit the site SEESSEESSEESSEESSEES your identityand your activity your IP, and a sealedsession it can't read enough to matchyou to an exit the destination,never your IP traffic arrivingfrom your exit No single party sees both who you are and what you do.
Four parties between you and the site, each seeing only its own slice. The seal is the encrypted session between you and the site: it passes through every hop unread, and your address is never on the exit's leg of the wire.
Part 3 · The dual role

One network, two roles

A residential provider — a member who shares their connection as an exit — can also serve as someone else's first hop. The extender role isn't a different kind of host; it's an activation of the same member identity. A host that carries both roles never plays both for the same path: your first hop and your exit are always two different members, so no single host is ever both ends of your connection. Running a first hop earns an equal share of the hop, the same as providing an exit. Today the dual role runs on desktop and the SDK; the mobile apps take part as clients.

One member, two roles: the same host is a first hop for one session and an exit for another, never both for yours Top: a card for a residential member. One session enters it from another client on a green lane and leaves toward the platform; the member is that client's first hop. A second session enters it from the platform on a blue lane and leaves toward a site; the member is someone else's exit. Bottom, your path: you, then your first hop (member X, green), then the platform, then your exit (member Y, blue), then the site. X and Y are always different members: no host is both ends of your connection. ONE MEMBER, TWO ROLES A residential member one identity, two activations AS A FIRST HOP another client to the platform AS AN EXIT the platform a site YOUR PATH Youfirst hopthe platformexitthe site member X matches you to Y member Y X and Y are always different members: no host is both ends of your connection.
The same member can be one person's first hop and another's exit, but never both for the same path: your first hop and your exit are always two different members.
Part 4 · Peer to peer

Peer-to-peer first hops

Fixed carriers need an address to answer on. Peer-to-peer removes that requirement: extenders reach each other directly over WebRTC — the transport browsers use for calls — so a first hop can be set up through NAT traversal even where no inbound port is open. It joins the carriers extenders already speak: TLS on 443, QUIC, and a DNS-shaped transport.

  • TLS on 443
  • QUIC
  • DNS-shaped
  • WebRTC, peer to peer
Part 5 · Staying unlisted

Resisting enumeration

A directory anyone can read is a directory a censor can harvest and block by address. URnetwork answers this the way bridge-based networks like Tor do: the directory is not handed out all at once. Addresses are partitioned and revealed gradually, so a watcher at one vantage point learns only a slice of the network rather than the whole of it, and the trust to see more is earned over time. This raises the cost of enumeration — it does not make a known address un-blockable, which is why extenders lean just as much on blending into ordinary traffic as on staying unlisted.

Resisting enumeration: a watcher at one vantage sees only a slice of the directory A field of dots stands for extender addresses. An eye at the left, one watcher's vantage, casts a narrow beam across the field; only the dots inside the beam are lit and the rest stay dim. A faint wider outline and an arrow below say that more is revealed as trust is earned over time. No counts are implied. ONE VANTAGE, ONE SLICE sees a slice the rest ofthe directory a watcherat one vantage more is revealed as trust is earned
The directory is not handed out all at once: one vantage learns a slice, and more is revealed as trust is earned. That raises the cost of enumeration; it does not make a known address un-blockable.
An extender is reachability you can find, trust you can reason about, and a role anyone can run — not one server you have to hope stays up.

How this page is scored

How cells were scored

The five goals and each cell's rule were fixed before any cell was filled. ● means the goal holds in the protocol's standard configuration, ◐ only in a non-default mode or with a material caveat (footnoted), — that it is absent. Where a cell rests on judgement rather than a checkable fact, the note says so.

What this page does not claim

This is a comparison of protocols, not products: no prices, jurisdictions, audits or refund policies — those live on the comparison map. It is not a ranking. And URnetwork is scoring a field that includes its own protocols, which is a conflict of interest stated plainly here.

Evidence and dates

Mechanism and blocking facts come from URnetwork's own overview, threat model and FAQ and from public measurement (OONI, Tor Metrics, gfw.report) over 2024–2026. No throughput numbers are invented; speed is characterized, not scored.

Last reviewed 2026-10-07Named but left off the table: Hysteria2 and TUIC (QUIC proxies), Psiphon and Conduit, OpenVPN, MASQUE, obfs4 and WebTunnel — each a close relative of a column here.

Try it

Use the apps if you want the extender path with nothing to set up: it is on in every app and the SDK, and a fresh install already has it. Run an extender if you want to be a way in for others — anyone can, and the provider role does it by default.

Get the apps Run an extender

How URnetwork works Threat model Comparison map

URnetwork docsProtocol comparison · reviewed 2026-10-07