Domain Fronting Is Not a VPN: Two Names, One Request

The two techniques get filed together because both involve an intermediary and both sound like hiding. They operate on different objects. Domain fronting is about which name appears at which layer of one HTTPS request. A VPN is about which packets take a particular path to a peer. Calling fronting a kind of VPN leads to designs that cannot work, and to reviews that ask the wrong question.

Two names, two layers

A TLS connection can carry a server name in its handshake. Once the connection exists, the HTTP request identifies the authority it wants, commonly in the Host header. Those are two fields read at two different moments by two different pieces of software.

Domain fronting exploits a difference between the first two so that a fronting service accepts the connection and then routes the request elsewhere. It works only where that service is willing to route it, which is a provider policy question rather than a protocol trick.

Fronting depends on the provider, not on the technique

For a bounded example, Azure's Front Door FAQ documents domain-fronting protections. It describes an allowed mismatch for domains within the same subscription and configured routes, and a 421 Misdirected Request response when the mismatch protection blocks a request.

That single documented policy kills both slogans at once. Not every pair of different names works, and not every mismatch is forbidden either. Other services have their own checks, their own deployment requirements and their own error codes.

It also is not an instruction for getting around another network's restrictions. Reading a provider's routing rules to understand what it permits is architecture work; treating those rules as a bypass recipe is a different activity with different consequences. Keep those two activities apart in the document you write. The second one is what gets a design rejected in review.

What a VPN actually selects

In a network VPN, routing and platform policy select inner traffic for a tunnel to a peer. Depending on the arrangement that can cover several applications or a defined subset, and it can carry protocols that have no HTTP request at all.

Fronting does none of that. Arranging one HTTPS request through a fronting service does not install a private-network route, does not carry arbitrary UDP applications, and does not make every program on the device use the service. If you need that coverage, you need a proxy or a tunnel, not a naming trick.

This is why the two get confused in review: both are described as intermediaries, and both appear in documents about access. The interface each one offers is completely different, and only one of them is a network path.

Visibility is not binary

Nor is the comparison simply hidden versus visible. DNS queries, destination addresses, handshake features, packet sizes and timing all remain observable to someone positioned to see them, and what that observer learns depends on where they sit.

Application data is also visible at the endpoints that terminate it. A fronting service that routes your request is one of those endpoints, and a VPN peer is another. Neither arrangement makes the content opaque to the party that has to read it to serve you.

Draw the three boxes

For an architecture review, draw the TLS endpoint, the HTTP routing service and the final application as three separate boxes, then draw any VPN peer somewhere else again. The place that chooses a web destination and the place that transports private-network packets need not be the same system, and usually are not.

Once the boxes are separate, the questions become answerable: which names does this provider accept, which protocols need carriage, and which party can see what. A diagram that merges them produces a design nobody can implement and a review that argues about vocabulary.