This is a terrible idea.

First of all, you're routing all plaintext HTTP requests and responses back and forth over the open internet. Absolutely everyone with network visibility can see the entire contents of every HTTP request. Even using HTTPS would result in people able to tie the requests to the .onion address due to TLS SNI.

Second of all, allowing the onion service direct access to the internet in the first place should be avoided. Most webserver hosting technologies are large and complex and were never designed with anonymity, privacy or proxy obedience in mind. They leak, and can be induced to make connections (in often unexpected ways) that can deanonymize them. I recently ran a scan of the entire Ahmia onion list and managed to cause approx. ~80 onions to perform DNS lookups, of my choosing, outside of Tor. If making connections across the internet to some remote host, then the simple ability to determine $_SERVER['REMOTE_ADDR'] or $_SERVER['SERVER_ADDR'] would be sufficient to discover the location of the server.

When people on the other ticket suggest running the web server and Tor on separate machines, they mean on a network that you control and only you have visibility of, be it a physical LAN or a virtual network undera hypervisor. By isolating the web server from direct internet access, you increase your resilience to exploitation or accidental leaks as a means of deanonymization.

[HTTPD] <--Local/Private Network--> [Tor Enforcment/Firewall] <--Tor Network--> [Attacker]

In the above scenario, an attacker who is able to exploit the HTTPD or web app is still unable to directly connect back to the internet without then also exploiting the Tor Enforcement/Firewall device, defeating many attackers and drastically increasing the cost and risk for others.

Setting this up properly is no simple task and comes with many of it's own caveats and potential pitfalls but if done right, it does have distinct advantages against sophisticated attackers.

However, in most cases simply using a local packet filter (e.g. iptables) to stop outbound connections outside of Tor and using 127.0.0.1 for your onion services would be sufficient (it would still require an additional privilege escalation exploit to bypass the network filter) to stop most attackers.

This is a terrible idea.

First of all, you're routing all plaintext HTTP requests and responses back and forth over the open internet. Absolutely everyone with network visibility can see the entire contents of every HTTP request. Even using HTTPS would result in people able to tie the requests to the .onion address due to TLS SNI.

Second of all, allowing the onion service direct access to the internet in the first place should be avoided. Most webserver hosting technologies are large and complex and were never designed with anonymity, privacy or proxy obedience in mind. They leak, and can be induced to make connections (in often unexpected ways) that can deanonymize them. I recently ran a scan of the entire Ahmia onion list and managed to cause approx. ~80 onions to perform DNS lookups, of my choosing, outside of Tor. If making connections across the internet to some remote host, then the simple ability to determine $_SERVER['REMOTE_ADDR'] or $_SERVER['SERVER_ADDR'] would be sufficient to discover the location of the server.

When people on the other ticket suggest running the web server and Tor on separate machines, they mean on a network that you control and only you have visibility of, be it a physical LAN or a virtual network undera hypervisor. By isolating the web server from direct internet access, you increase your resilience to exploitation or accidental leaks as a means of deanonymization.

[HTTPD] <--Local/Private Network--> [Tor Enforcment/Firewall] <--Tor Network--> [Attacker]

In the above scenario, an attacker who is able to exploit the HTTPD or web app is still unable to directly connect back to the internet without then also exploiting the Tor Enforcement/Firewall device, defeating many attackers and drastically increasing the cost and risk for others.

Setting this up properly is no simple task and comes with many of it's own caveats and potential pitfalls but if done right, it does have distinct advantages against sophisticated attackers.

However, in most cases simply using a local packet filter (e.g. iptables) to stop outbound connections outside of Tor and using 127.0.0.1 for your onion services would be sufficient (it would still require an additional privilege escalation exploit to bypass the network filter) to stop most attackers.