When people first encounter Tor Onion Services, one detail often seems almost paradoxical:

How can a server be reachable from anywhere on the Internet if users do not know its IP address?

On the ordinary Internet, a public server normally has to reveal where it is.

A website such as:

example.com

is usually resolved through DNS:

example.com
    ↓
DNS
    ↓
203.0.113.10
    ↓
Web Server

The client eventually connects toward the server’s IP address.

An Onion Service works very differently.

Instead of publishing a server IP address, Tor allows a service to publish a cryptographic identity and establish connections entirely through the Tor network.

This is the basic idea behind what is sometimes informally called an Onion server.

---

1. “Onion Server” Is Not a Special Kind of Hardware

There is no special physical machine called an Onion server.

An Onion Service can run on an ordinary computer:

• Linux server
• VPS
• desktop computer
• Raspberry Pi
• virtual machine
• container host
• home server

The machine itself can be completely ordinary.

What makes it an Onion Service is the presence of Tor software configured to publish a local service through the Tor network.

For example, a machine might already have a web application running locally:

127.0.0.1:8080

Without Tor, that service is only accessible from the same machine.

With an Onion Service:

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.onion
                        ↓
                    Tor Network
                        ↓
                  Tor Service
                        ↓
                  127.0.0.1:8080

Now a Tor user can reach that local application from anywhere.

The web application itself does not need to understand Tor.

It may simply be:

• Nginx
• Apache
• Caddy
• a Python application
• Node.js
• a self-hosted web interface

Tor provides the anonymous transport layer around it.

---

2. The Server Does Not Publish Its Public IP Address

This is one of the most important differences from ordinary hosting.

A traditional public website usually exposes a chain such as:

Domain
  ↓
DNS
  ↓
Public IP
  ↓
Router / Firewall
  ↓
Server

If a website is hosted at home, the architecture may look like:

Internet
   ↓
Public IP
   ↓
Home Router
   ↓
Port Forwarding
   ↓
Internal Server

Anyone connecting to the server can normally determine the public IP address.

An Onion Service changes the model:

Tor Client
    ↓
Tor Network
    ↓
Onion Service
    ↓
Local Application

The client does not need to know the server’s public IP.

Instead, both sides communicate through Tor circuits.

This creates a very unusual property:

A service can have a stable public address without publishing its physical network location.

---

3. The .onion Address Is the Service Identity

On the ordinary web, a domain name and a server are conceptually separate.

For example:

example.com

is registered through the domain-name system and later configured to point toward a server.

An Onion Service does not work that way.

Modern Onion Services use a cryptographic key pair.

Conceptually:

Private Key
    ↓
Public Key
    ↓
Encoded identity information
    ↓
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.onion

The .onion address is therefore closely related to the cryptographic identity of the service.

There is no conventional process equivalent to:

Buy domain
↓
Register domain
↓
Configure authoritative DNS
↓
Point DNS record to IP

Instead:

Generate Onion Service keys
↓
Derive .onion address
↓
Publish service through Tor

This is why .onion addresses are long and apparently random.

They are not primarily human-readable names.

They represent cryptographic identities.

---

4. There Is No Ordinary DNS Lookup

Suppose a Tor Browser user enters:

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.onion

The browser does not send that address to:

Google DNS
Cloudflare DNS
ISP DNS
DNS Root Servers

The normal DNS hierarchy is not responsible for .onion.

Instead, Tor uses its own Onion Service discovery system.

This means the question is not:

“What IP address corresponds to this hostname?”

The question is closer to:

“How can a Tor client establish a secure anonymous connection with the service that owns this cryptographic identity?”

That distinction is fundamental.

---

5. The Onion Service First Creates Introduction Points

An Onion Service needs some way for clients to begin contacting it.

But it cannot simply publish:

Onion address → Server IP

That would immediately reveal the server.

Instead, the Onion Service establishes Tor circuits to several relays called:

Introduction Points

Conceptually:

             Introduction Point A
            /
Onion Server ─ Introduction Point B
            \
             Introduction Point C

More accurately:

Onion Service
      │
      ├── Tor circuit ── Introduction Point A
      │
      ├── Tor circuit ── Introduction Point B
      │
      └── Tor circuit ── Introduction Point C

The introduction points do not need to know the real-world identity of the service.

They simply act as controlled contact points inside the Tor network.

---

6. The Service Publishes a Descriptor

The Onion Service then creates information describing how clients can initiate contact.

This information is called an:

Onion Service Descriptor

The descriptor contains information related to the service’s introduction mechanism.

It does not simply publish the server’s public IP address.

The descriptor is stored on selected Tor relays that perform the role of:

HSDir — Hidden Service Directory

Conceptually:

Onion Service
      │
      │ publish descriptor
      ▼
   HSDir Relays

These directories form part of a distributed system.

This is somewhat analogous to a directory service, but it is fundamentally different from ordinary DNS.

---

7. A Client Finds the Service Without Learning Its IP

When Tor Browser receives an Onion address, it uses information derived from that address and the Tor network state to locate the appropriate service descriptor.

Conceptually:

Tor Browser
     │
     │ .onion address
     ▼
Tor Network
     │
     ▼
HSDir
     │
     ▼
Service Descriptor

The descriptor tells the client enough to begin communicating with the Onion Service.

Crucially, the descriptor does not need to reveal:

Server public IP

The client learns how to contact the service through Tor, rather than where the server physically exists on the Internet.

---

8. The Client Does Not Connect Directly to the Server

This is the most elegant part of the Onion Service architecture.

The client chooses another Tor relay to become a:

Rendezvous Point

The client creates a Tor circuit toward it:

Client
   │
   │ Tor Circuit
   ▼
Rendezvous Point

The client then sends information through one of the service’s Introduction Points indicating where it would like the service to meet.

Conceptually:

Client
   │
   ▼
Introduction Point
   │
   ▼
Onion Service

The Onion Service then independently creates its own Tor circuit toward the Rendezvous Point.

Eventually:

Client
   │
   │ Tor Circuit
   ▼
Rendezvous Point
   ▲
   │ Tor Circuit
   │
Onion Service

The two parties meet inside the Tor network.

Neither side needs to establish a direct Internet connection to the other.

---

9. There Is No Tor Exit Relay

This is another major difference between ordinary Tor browsing and Onion Services.

When accessing a normal public website through Tor:

Client
   ↓
Tor Guard
   ↓
Tor Relay
   ↓
Tor Exit
   ↓
Normal Website

Eventually traffic must leave Tor and enter the ordinary Internet.

That requires an Exit Relay.

With an Onion Service:

Client
   ↓
Tor
   ↓
Rendezvous
   ↑
Tor
   ↑
Onion Service

The communication remains inside the Tor network.

There is no conventional Tor exit.

This brings several important consequences:

• the server does not see the client’s real IP;
• the client does not see the server’s real IP;
• no exit relay is needed;
• communication is protected by the Onion Service protocol;
• both sides communicate through Tor circuits.

This is why Onion Services are sometimes described as providing anonymity to both ends of the connection.

---

10. Why Port Forwarding May Be Unnecessary

This is one of the most practical consequences of the architecture.

Consider a normal server behind a home router.

Its internal address might be:

192.168.x.x

The server cannot normally accept connections directly from the Internet because NAT separates the private network from the public Internet.

Traditional hosting therefore requires something like:

Internet
    ↓
Public IP
    ↓
Router
    ↓
Port Forwarding
    ↓
192.168.x.x:443

The router must explicitly allow inbound traffic.

An Onion Service does not work this way.

The server itself establishes outbound Tor connections.

Conceptually:

Home Server
     │
     │ outbound connection
     ▼
Tor Network

A remote client also connects outbound into Tor:

Remote Client
     │
     ▼
Tor Network

The Tor network then brings the two sides together.

So the architecture becomes:

                 Tor Network
                /           \
               /             \
     Tor Client               Home Server
                                  │
                              Local Service

The home router does not necessarily need to accept a direct public inbound connection to the application.

Therefore:

An Onion Service can often expose a service globally without traditional port forwarding.

This is particularly useful behind:

• NAT
• carrier-grade NAT
• changing public IP addresses
• restrictive inbound firewalls

provided outbound Tor connectivity is available.

---

11. Dynamic Public IP Addresses Become Much Less Important

Traditional self-hosting often depends heavily on a public IP address.

If the address changes:

Old IP
   ↓
Disconnected
   ↓
New IP
   ↓
Update Dynamic DNS

This is why many home servers use Dynamic DNS.

An Onion Service is different.

Its identity is based on cryptographic keys rather than the current public IP address.

Therefore:

Public IP changes
        ↓
Tor reconnects
        ↓
Same Onion Service identity
        ↓
Same .onion address

As long as the Onion Service retains its private key, the Onion address can remain the same.

This effectively separates:

service identity

from:

network location

That is a major architectural difference from conventional Internet hosting.

---

12. A Stable Address Without a Stable Location

This property is worth emphasizing.

Traditional hosting typically assumes:

Stable service
      ↓
Stable DNS
      ↓
Known network destination

Tor allows:

Stable service identity
        ↓
Stable .onion address
        ↓
Changing or hidden physical network location

A server could theoretically:

• change ISP;
• move to another network;
• obtain another public IP;
• move behind another router;
• move from one machine to another;

while retaining the same Onion Service identity, provided the necessary Onion Service private keys are transferred securely.

From the client’s perspective, the Onion address remains unchanged.

---

13. The Application Can Listen Only on Localhost

Another useful security property is that the actual application does not necessarily need to listen on a public network interface.

For example:

Web Application
127.0.0.1:8080

Tor can be configured conceptually as:

.onion:80
    ↓
127.0.0.1:8080

The application remains bound to localhost:

Internet ──X──> 127.0.0.1:8080

but Tor can reach it locally:

Tor Process ─────> 127.0.0.1:8080

This provides a clean separation:

External world
      ↓
Tor
      ↓
Local service

instead of:

External world
      ↓
Open firewall port
      ↓
Publicly listening web server

It does not eliminate the need for normal application security, but it can significantly reduce direct network exposure.

---

14. An Onion Service Does Not Have to Be a Website

The word “server” often creates the impression that Onion Services are only web servers.

That is not true.

Tor transports TCP connections, so many TCP-based services can potentially be exposed through Onion Services.

Conceptually:

Onion Service
├─ HTTP website
├─ HTTPS website
├─ SSH
├─ chat server
├─ file transfer service
├─ custom API
└─ custom TCP application

For example:

xxxxxxxx...onion:22
        ↓
       Tor
        ↓
127.0.0.1:22
        ↓
       SSH

The Onion Service acts as an anonymous network-access layer.

The underlying application may remain almost completely unaware that Tor exists.

---

15. Client Anonymity and Server Anonymity Are Different Problems

Ordinary Tor browsing mainly protects the client.

For example:

Client
   ↓
Tor
   ↓
Exit
   ↓
example.com

The website is public and its infrastructure can generally be located.

Tor hides the client from the website.

An Onion Service protects both sides differently:

Anonymous Client
       ↓
      Tor
       ↓
Anonymous Service

The client does not need to know the server’s IP.

The server does not need to know the client’s IP.

This creates a symmetrical architecture that ordinary web hosting does not provide.

---

16. The Server Is Hidden, but Not Magically Invulnerable

Hiding the network location does not make the application secure by itself.

An Onion Service can still contain:

• vulnerable software;
• weak passwords;
• application bugs;
• misconfigured permissions;
• outdated dependencies;
• information leaks;
• identifying metadata.

For example, an application might accidentally display:

internal hostname
public hostname
email address
software paths
server metadata

or make separate outbound connections outside Tor.

Such mistakes can reveal information independently of the Onion protocol.

Therefore:

Network-location anonymity and application security are separate problems.

Tor protects the transport architecture.

The service still needs normal security engineering.

---

17. An Onion Service Is Not a VPN Tunnel

It is also useful to distinguish Onion Services from VPNs.

A VPN typically creates:

Device
   ↓
Encrypted Tunnel
   ↓
VPN Server
   ↓
Internet

The VPN server acts as a network gateway.

An Onion Service instead creates a service endpoint inside Tor:

Client
   ↓
Tor Network
   ↓
Rendezvous
   ↑
Tor Network
   ↑
Service

There is no requirement for a single central gateway that knows both endpoints.

The architecture and trust model are fundamentally different.

---

18. Why This Architecture Is Unusual

Traditional Internet architecture often exposes location as part of communication.

To connect to something, a client usually needs to know where it is.

Conceptually:

Identity
   ↓
Address
   ↓
Location
   ↓
Connection

Tor Onion Services break this relationship.

They allow:

Identity
   ↓
Cryptographic Onion Address
   ↓
Anonymous Rendezvous
   ↓
Connection

The physical server location does not have to be revealed as part of service discovery.

This can be summarized as:

Connect to an identity instead of connecting to a location.

That is perhaps the most important conceptual difference between an Onion Service and an ordinary Internet server.

---

19. Ordinary Hosting and Onion Hosting Compared

Property	Ordinary Internet Server	Onion Service
Address	Domain name	.onion address
Name system	DNS	Tor Onion Service mechanism
Address registration	Usually required for domain	Not required
Public IP normally exposed	Yes	No
Server location discoverable	Usually	Designed to be hidden
Port forwarding behind NAT	Often required	Often unnecessary
Static public IP required	No, but useful	Not required
Dynamic DNS useful	Often	Usually unnecessary
Client knows server IP	Normally yes	No
Server knows client IP	Normally yes	No
Tor exit relay required	N/A or yes when reached through Tor	No
Cryptographic service identity	Usually certificate-based	Built into Onion identity
Works behind NAT	With forwarding or tunneling	Often directly via outbound Tor

The important difference is not simply encryption.

It is the network architecture itself.

---

20. The Deeper Idea: Separating Identity From Location

The ordinary Internet tightly couples several concepts:

Domain
   ↓
IP address
   ↓
Network
   ↓
Physical server

An Onion Service deliberately weakens those relationships.

Cryptographic identity
        ↓
    .onion address
        ↓
      Tor
        ↓
Hidden network location

The address represents who the service cryptographically is, not simply where the server currently resides.

This is why Onion Services can provide capabilities that initially appear surprising:

• a server can be globally reachable without publicly advertising its IP address;
• it can operate behind NAT without conventional inbound port forwarding;
• its public IP can change without changing its Onion identity;
• both client and server can avoid directly learning each other’s IP addresses;
• no conventional DNS registration is necessary;
• the entire connection can remain inside the Tor network.

An “Onion server” is therefore not really a special server at all.

It is an ordinary service placed behind an extraordinary addressing and routing architecture.

The most important idea can be reduced to one sentence:

An Onion Service allows the Internet to reach a service by cryptographic identity rather than by directly exposing its physical network location.