Who Sees What
Awazon market onion addresses
awazonloedcyl2otgftfg7qm6e2klbgg2dhouyli3hdno6gdkueh6byd.onion
awazonozc4jwyrveu4473igv5ldt2hnccl2s7lerm2z27cvrc22e4uyd.onion
awazonth6ocz5cyos63czmhtsglqr7ydkdcc4lopux7nxbauoo2qmvyd.onion

Printed exactly as supplied, in the order supplied, with no labels and no ranking between them. This site runs no checks against any of them. It publishes no uptime figure, no status light and no date of last checking, because it never looks. An address that opens is not by itself evidence of anything.

Adding a VPN to Tor, and which observer it moves

A VPN can sit before Tor or after it. In both cases the honest description is the same: an observer is displaced rather than deleted, and a new one is created.

Who sees it

A VPN provider · Your ISP · Whoever holds the payment record

Arrangement one: VPN first, then Tor

Your machine connects to a provider and the Tor client runs inside that connection. Your ISP now sees a steady encrypted connection to a company rather than to a machine publicly listed as a relay. The conclusion available on your line changes from this subscriber uses Tor to this subscriber uses a VPN.

The provider now holds the position your ISP used to, and slightly more. It sees your real network address, it sees that the traffic inside is going to a Tor relay, and it sees times and volumes. Your first relay is handed the provider address instead of yours.

The trade is a swap. What you gain is that the party billing you for your line no longer sees Tor. What you accept is that a different company sees exactly that, and unlike a relay operator it has your account details.

Arrangement two: Tor first, then VPN

Here the traffic leaves Tor and enters a provider before reaching a destination. The first thing to say is specific to what this site covers: for an address ending in .onion there is no exit relay, so there is no point in the path where a VPN could be inserted afterwards. The arrangement is inert for that case, as exits and onion addresses explains.

For ordinary websites it replaces a rotating stranger with a fixed one. Instead of a different exit operator each time, every connection appears to come from the same provider endpoint, tied to an account, so a destination sees one durable identifier across sessions rather than a series of unrelated exits.

It also puts the provider in the position of seeing your destinations, which the exit would otherwise have held. Your ISP still sees Tor on the line, because the connection into the network is unchanged.

What both arrangements have in common

Whichever order they are in, adding a provider adds a commercial relationship, and a commercial relationship generates records that a relay never does. There is a signup, with whatever identifier the account was created against. There is a payment, which is the part people underweight, because a payment usually ties an account to a name, a bank or a service. There is a jurisdiction, and often support correspondence and an application that runs at startup.

A relay operator has none of that. They have a connection from an address and no account for you at all. The comparison to make is not encrypted against unencrypted. It is anonymous stranger against identified counterparty.

No provider
Your ISP sees a relay connection. Your first relay sees your address. No account exists.
Provider before Tor
Your ISP sees a provider. The provider sees your address and that it is Tor. Your first relay sees the provider.
Provider after Tor
Nothing changes for an onion address. For ordinary sites the provider replaces the exit view and becomes a fixed endpoint.
Both arrangements
A company holds an account, a payment record and a jurisdiction. None of that existed before.

What neither arrangement touches

No arrangement of tunnels changes what the far end recorded, because you sent it that information on purpose. The account name, the messages and the order history are unaffected. That is registering an account and the cards after it.

Nothing here reaches a parcel either. A physical object is handled by people who have never heard of any of this, which is the outside of the packet. Nor does it change what is written on your own disk, covered in what lands on the disk.

Why this card does not recommend anything

The site names no provider and rates none, and that is not a hedge. What a company says it keeps is a claim, and a claim is not an observable. From your side of the connection there is no way to confirm what is recorded, how long it is held, or what happens when it is asked for. Every card here is written about things that can be reasoned about from the outside.

What can be reasoned about is structural, and it is stated above: which party sees your address, which sees that Tor is in use, and which has an account with your payment attached. Weighing an ISP against a chosen company is a judgement about which record you would rather exist, and that depends on circumstances this page knows nothing about.

For the narrower problem of a line where a Tor connection would itself be conspicuous, a bridge is the mechanism designed for it and involves no account or payment. That is turning on a bridge, a different trade with different costs.

What changes the answer

5 things change how much this action gives away. None of them takes it to zero, and none of them is a promise.

  1. Count the accounts, not just the tunnelsThe durable part of a provider is not the encryption, it is the signup and the payment. Ask what identifier the account sits on before asking what the tunnel does, because that record outlives any session.
  2. Decide which single observer you are trying to moveA provider before Tor moves the Tor observation from your ISP to a company. A provider after Tor does nothing for onion addresses. If you cannot name the observer being moved, the arrangement adds parties for no gain.
  3. Your first relay persists either wayAdding a provider changes the address your first relay is handed, not the fact that it keeps its position for a long time. See the entry guard for why that stability exists.
  4. A bridge is the narrower tool for the narrower problemIf the concern is only that a Tor connection is visible on your line, turning on a bridge addresses that without introducing a billing relationship.
  5. Nothing here reduces what you hand over yourselfThe largest disclosure in this catalogue is voluntary and happens at the far end. No tunnel affects typing a delivery address into a form.

What this card is not

This card does not recommend an arrangement, name a provider or judge one. It lists who is added and who is displaced, and stops there.

Questions that come up

Does a VPN before Tor hide Tor from my ISP?

It replaces what your ISP sees with a connection to the provider, so the Tor observation moves to that company rather than disappearing. The provider then holds it, alongside an account and a payment record.

Is a VPN after Tor useful for an onion address?

There is no exit relay in the path for an address ending in .onion, so there is no position where a provider could be inserted afterwards. For that case the arrangement changes nothing.

Which arrangement does this site recommend?

Neither. Provider behaviour is a claim rather than something observable from your side, so the card sets out which party sees what and leaves the judgement there.