Most WordPress sites sit behind Cloudflare or a similar edge network, and most site owners assume that means the origin is protected. It often is, for traffic that goes through the edge. But the origin server usually still has port 80 and 443 open to the world, waiting for connections from anyone who knows its IP address. If that IP leaks, and it leaks more often than people expect, the edge protection can be walked right around. Zero inbound ports is a different model. The origin makes an outbound connection to the edge and never listens for inbound traffic at all. There is nothing to scan, nothing to flood, and nothing to exploit directly, because there is no open door to find.
This article explains how that model works, what it removes as an attack surface, and where the tradeoffs show up.
The origin IP problem
Cloudflare in front of a site provides edge caching, a web application firewall, bot mitigation, DDoS protection, and Universal SSL. All of that is real protection, but it only applies to requests that actually reach Cloudflare first. If someone connects directly to your origin’s IP address on port 80 or 443, none of the edge rules apply. They are talking straight to your server.
Origin IPs leak more easily than people assume. Old DNS records that predate the Cloudflare setup, subdomains that were never proxied, mail server records, SSL certificate transparency logs, and even misconfigured plugins that reveal server headers can all point back to the real address. Once an attacker has it, they can hit the server directly with a denial-of-service flood, run a vulnerability scanner against exposed services, or brute-force SSH and any other open port, all while your edge dashboard shows nothing unusual because none of it goes through the edge.
Keeping the origin IP unpublished is a real mitigation on its own, and it is worth doing. But an IP that exists and has open ports can always be found eventually. A tunnel removes the open ports instead of just hiding the address.
How outbound-only tunnels work
In the tunnel model, a lightweight daemon runs on the origin server and initiates an outbound connection to the edge network’s infrastructure. That connection stays open. When a visitor’s request arrives at the edge, it gets routed back down that existing outbound tunnel to the origin, gets processed, and the response travels back the same way.
The important detail is direction. The origin never accepts an inbound connection on 80 or 443. Those ports can be closed at the firewall entirely. The only traffic the server sends is outbound, to a known, trusted destination. From the outside, a port scan against the origin’s public IP finds nothing listening, because nothing is.
This is a fundamentally different security posture than “firewall rules that only allow Cloudflare’s IP ranges,” which is the older approach. IP allowlisting still requires an open, listening port that trusts a specific range. A tunnel requires no listening port at all. The difference matters because allowlists can be bypassed by IP spoofing or misconfiguration, while a closed port cannot be connected to regardless of the source address.
What this kills as an attack class
Removing inbound listening ports eliminates several attack categories outright rather than just mitigating them:
- Direct-to-origin DDoS. A volumetric flood needs something to flood. If there is no open port, the flood has nowhere to land, and the origin’s bandwidth and connection tables are never touched.
- Port scanning and service fingerprinting. Tools that probe for open ports, banner-grab service versions, or look for forgotten admin panels find a server that answers nothing on any port.
- Direct exploit attempts against web server or SSH software. An attacker who knows a specific vulnerability in a web server or SSH daemon still needs to reach that service to use it. With no inbound path, the exploit has no delivery mechanism.
- Origin IP discovery becoming useful. Finding the origin IP still tells an attacker where the server lives, but it no longer tells them anything they can act on, since there is no service to connect to at that address.
None of this replaces application-level security. A vulnerable plugin is still vulnerable if the request reaches WordPress through the tunnel and the edge WAF. What changes is the set of attacks that require a direct network path to the origin, which is a meaningful and often underappreciated slice of real-world attack traffic.
The tradeoffs
Nothing here is free. A few honest tradeoffs to know before adopting this model:
- The tunnel daemon becomes a dependency. If it crashes or the process is not monitored, the site goes down even though the server itself is healthy. It needs the same uptime attention as any other critical service.
- Debugging changes. You can no longer
curlthe origin IP directly to isolate whether a problem is at the edge or the origin, since there is no direct path to test. Diagnosis has to happen from the tunnel logs or from the origin’s local perspective. - You are trusting the tunnel provider’s edge network completely. All traffic to your site now depends on that provider’s availability and routing. This is the same trust you already place in any CDN or edge network, but it becomes total once the direct path is removed.
- Software updates matter more, not less. With no inbound attack surface, the tunnel daemon itself becomes a more attractive target, so keeping it patched is not optional.
None of these are reasons to avoid the approach. They are reasons to treat the tunnel as infrastructure that needs the same monitoring discipline as the database or the web server itself.
Where this fits with the rest of the stack
Zero inbound ports is a network-layer control. It does not replace the rest of a solid WordPress security setup: keeping PHP current (PHP 8.1 through 8.3 is the mainstream range today, with PHP 8.3 plus OPcache a solid default), running LiteSpeed Cache with Redis or Memcached for object caching, and keeping plugins and core updated through wp-cli or the dashboard. It also does not replace the edge WAF and bot mitigation that Cloudflare or a similar provider offers for traffic that does reach the site normally. What it does is remove the option of going around all of that by connecting directly to the server.
Some managed WordPress hosts, ServerBorn included, run this tunnel architecture by default so that the origin has no inbound attack surface at all, without the site owner having to set up or maintain the tunnel daemon themselves.
Takeaway
An open port is an open port, no matter how good the firewall rules in front of it are. Outbound-only tunnels remove the port entirely, which quietly eliminates direct DDoS, port scanning, and direct exploit delivery as viable attacks against the origin. The cost is a new dependency to monitor and a debugging workflow that changes. For most WordPress sites, that is a trade worth making.