Chains and Multihop: What They Give You and What They Cost

A second hop solves specific problems and creates new ones. What a chain actually buys, why a fallback path is not failover, and the trace multihop leaves in traffic.

2026-08-31 GIGATAP Team #vpn
#vpn#anticensorship#multihop#network#architecture

Chains and Multihop: What They Give You and What They Cost

A multihop setup looks like an obvious upgrade: more links, harder to trace, more reliable circumvention. Both halves of that sentence need qualifying. A second hop does solve several specific problems, but it pays in latency, in reliability and in a new trace left in the traffic — and none of those costs is obvious in advance.

Here is what a chain actually solves, what it creates, and one widespread misconception about the failover mechanism.

What does a chain solve?#

Separation of knowledge. The value lies not in the number of links but in the fact that no single node sees both who you are and where you are going.

ONE HOP
client ──────────────► node ──────────► destination
                        │
                        └── knows: WHO you are and WHERE you go

TWO HOPS
client ──────► entry ──────► exit ──────► destination
                │              │
                │              └── knows WHERE, not WHO
                └── knows WHO, not WHERE

This is a property of the architecture, not a function of count: three hops do not deliver it more strongly than two, if two already separate the knowledge.

Position in the network. The second use is more pragmatic: the entry sits where different rules apply to it than to a foreign address. Here the second hop is not about privacy but about making the first leg of the path look different.

A widespread misconception: a fallback path is not failover#

Xray has a fallbacks mechanism, and its purpose is routinely misunderstood.

fallbacks sends a connection that failed authentication to a different handler. It is protection against active probing: a stranger knocking on the port receives a plausible response instead of a distinctive refusal.

It is not failover. If the destination server is unreachable, fallbacks will not move traffic to another node — the mechanism triggers on failed authentication, not on unavailability.

Real health-aware switching comes from a different pair: a balancer with a list of outbound legs, plus an observatory that checks those legs periodically.

Mechanism Triggers on Purpose
fallbacks failed authentication anti-probing
balancer + observatory an unreachable leg failover

The confusion is expensive: a configuration with fallbacks but no balancer looks fault-tolerant and is not.

An observatory subtlety that breaks expectations#

The balancer-plus-observatory pairing has a documented property worth knowing in advance.

The observatory builds its list of watched legs at start-up. Legs registered later — dynamically, after launch — stay invisible to it for a while: the Xray tracker documents delays of up to ten minutes.

The practical consequence:

node restart
   │
   ├── balancer is up, legs are registered
   ├── observatory has NOT checked them yet
   │
   ▼
window of up to ~10 minutes: leg selection happens BLIND
   not because every leg is healthy,
   but because none has been checked

Hence the rule: balancer legs are declared statically, and after every restart it is worth confirming the observatory sees them before treating the node as accepted.

What a chain costs#

Every link adds overhead, and not all of it is obvious.

Cost What happens
Latency two network legs add up instead of one
MTU a tunnel inside a tunnel shrinks usable packet size
Points of failure any link falling takes the whole chain down
Diagnostic difficulty a failure anywhere looks identical from outside
Extra RTT an observable trait, see below

The MTU row is underrated: outer and inner transport headers eat into the packet, and a miscalculation produces fragmentation — which is rare in ordinary traffic and therefore conspicuous.

The trace that multihop itself leaves#

A separate class of problem: a chain is observable as a chain.

A proxy inevitably adds a network path. Even with content fully encrypted, correlation between inner-protocol events and outer reactions can expose the extra RTT. Research published in 2025 examines such cross-layer traits as a way to separate proxied traffic from direct traffic.

DIRECT CONNECTION
request ──► response
        │◄─ 30 ms ─►│

THROUGH A CHAIN
request ──► entry ──► exit ──► response
        │◄──────── 95 ms ────────►│
                  └── latency adds up and is observable

This does not mean multihop should be avoided. It means adding a link is not a free upgrade: it improves separation of knowledge and worsens statistical indistinguishability.

A practical criterion: every link must answer what it adds, and the answer cannot be “just in case”.

Links When it is justified
1 the goal is access; no separation of knowledge required
2 knowledge must be separated, or the entry needs a different network position
3+ rarely; each extra link must answer for a specific threat

Three links do not protect noticeably better than two, if two already separate the knowledge. They do add latency, another point of failure, and a stronger observable trait.

Conclusion#

A chain is a tool for separating knowledge and changing network position, not a general-purpose upgrade.

Two practical takeaways. First: do not confuse fallbacks with fault tolerance — they are different mechanisms with different triggers, and a configuration carrying one instead of the other looks protected without being so.

Second: every link is paid for in latency, MTU and an observable trace. Add one against a specific threat, not on the principle that more is better.

Terms#

  • Hop - a single intermediate link on the path from client to exit point.
  • Fallback path - a pre-arranged alternative route that requires switching manually or on a schedule.
  • Failover - an automatic switch to a backup route at the moment a problem is detected.

FAQ#

Does a second hop give automatic resilience?#

No. A fallback path and failover are different things. Having a second route does not mean anything will switch to it.

The smallest number that solves the stated problem. Every extra link adds latency and one more point of failure.

Is multihop itself visible?#

Indirectly, yes. The character of the delays and the shape of the stream differ from a single connection, and that difference is observable.

Further reading#