In normal Tor usage, the client sends a request through three chosen hops, each of which only knows the previous and next hops, so the entry node doesn't know the destination and the exit node doesn't know where the request originated. But this only hides the client, because the client needs to know the server's address to direct the exit node where to send the request. So to hide the server, there is a symmetrical setup with three extra hops on the server's side, and a published "rendezvous" address in the middle. So the server connects to the rendezvous without revealing its real IP, and the client can direct requests to the rendezvous without knowing the server's IP.

^ is the most informative comment in the whole thread.

So by 'hosting' they mean being the rendezvous address?

If I'm reading this right, it actually hosted the websites but its IP address was hidden. I don't know if each site maybe got its own IP on the host, because after all I'd think it would be trivial for a customer to upload some code to unmask the host's actual IP. https://web.archive.org/web/20170830191551/https://hosting.d...

If the .onion host is competent, they use iptables to restrict output to the Tor process.

No, by "hosting" they mean shared hosting, with multiple .onion sites on one physical server.

Each of those .onion sites would have its own Tor entry guard relays, and would negotiate its own rendezvous points. An .onion service, just like a Tor user, selects a few entry guards that it uses consistently. And gradually replaces with new ones, over some weeks. But rendezvous points get picked fresh for each client-server connection.

Only if you're omniscient in the network. No single node knows what traffic it's carrying, or that the next node the traffic is meant to be sent to is the final one.