I set up a testing environment made of lxd containers on Ubuntu 18.04. Each container is based on the Ubuntu 18.04 image and runs Tor version Specifically, I have the following running machines:

  • 3 Authorities (named as TorAuthoritity[01,02,03])
  • 3 Exit Relays (named as TorRelay[01,02,03]Exit)
  • 3 non-Exit Relays (named as TorRelay[04,05,06])
  • 1 Hidden Service (named as TorHs01)
  • 1 Client (named as TorClient01)

The torrc file has the "TestingTorNetwork 1" configuration value.

Moreover, only the torrc of Exit Relays has the following configuration values:

ExitRelay 1
ExitPolicy accept *:*

whereas all the other torrc files (i.e., Authorities and non-Exit Relays) have the following configuration values:

ExitRelay 0
ExitPolicy reject *:*

All the Tor relays and hidden service are configured in order to use the three Authorities

However, I noticed that the Hidden Service is always connected to one or more non-Exit Relays whereas I expected to see only connections to Exit Relays. For example, by running the command "lsof -i" on the container providing the Hidden Service, I get the following result:

root@TorHs01:~# lsof -i
systemd-n 180 systemd-network   14u  IPv4 128314      0t0  UDP TorHs01.lxd:bootpc 
systemd-r 182 systemd-resolve   12u  IPv4  52219      0t0  UDP localhost:domain 
systemd-r 182 systemd-resolve   13u  IPv4  52240      0t0  TCP localhost:domain (LISTEN)
sshd      251            root    3u  IPv4  77216      0t0  TCP *:ssh (LISTEN)
sshd      251            root    4u  IPv6  77314      0t0  TCP *:ssh (LISTEN)
apache2   260            root    4u  IPv6  81261      0t0  TCP *:8050 (LISTEN)
apache2   272        www-data    4u  IPv6  81261      0t0  TCP *:8050 (LISTEN)
apache2   273        www-data    4u  IPv6  81261      0t0  TCP *:8050 (LISTEN)
apache2   274        www-data    4u  IPv6  81261      0t0  TCP *:8050 (LISTEN)
apache2   275        www-data    4u  IPv6  81261      0t0  TCP *:8050 (LISTEN)
apache2   276        www-data    4u  IPv6  81261      0t0  TCP *:8050 (LISTEN)
tor       396             tor    9u  IPv4 116948      0t0  TCP localhost:9050 (LISTEN)
tor       396             tor   14u  IPv4 117902      0t0  TCP TorHs01.lxd:54948->TorAuthority03.lxd:5000 (ESTABLISHED)
tor       396             tor   15u  IPv4 117904      0t0  TCP TorHs01.lxd:41538->TorRelay02Exit.lxd:5000 (ESTABLISHED)

where the last two lines represent connections to TorAuthority03 (which is configured as a non-Exit Relay) and TorRelay02Exit (which is configured as an Exit Relay) respectively.

Generally, the Hidden Service is always connected at least to a non-Exit Relay (e.g., TorRelay04, TorAuthority03, etc) whereas I expected that the Hidden Service was only connected to Exit Relays (in my lxd environment, TorRelay01Exit, TorRelay02Exit, TorRelay03Exit).

Looking at the network traffic through Wireshark, it looks like the Hidden Service is using a non-Exit Relay as an exit node, although the consensus already includes the three Exit Relays in my testing environment. Is this behavior related to the testing environment only? If yes, do you already know why this happens? Is it possible to avoid this behavior?

Thanks a lot

  • Can you share with us the torrc of your DA, relay and client please? Commented Mar 13, 2020 at 20:27

1 Answer 1


What makes you expect that a hidden service will connect to an exit relay? A hidden service makes a circuit to a relay acting as a rendezvous, and the client makes a circuit to that same rendezvous relay, and the rendezvous transfers the cells between the client's circuit and the hidden service's circuit. Exit relays are only used to exit the Tor network onto the regular ol' Internet (hence the name). If the traffic never leaves the Tor network, it doesn't need an exit node.

  • thank you very much for this clarification. I was errouneously referring to exit nodes as the nodes responsible to be the first hop for the hidden service in the circuit from the hidden service to the rendezvous point. As you mentioned, I should expect that the hidden service connects to the nodes flagged as "Guard" and this is what is happening in my testing environment. I am sorry for the confusion, it was my mistake. Thank you very much for providing this clarification. It was very helpful.
    – Lewis
    Commented Oct 17, 2019 at 16:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .