---
title: "Entrance IPs vs. Exit IPs for Anonymizing Tunnels"
type: "explainer"
url: "https://docs.spur.us/knowledgebase/explainers/entrance-vs-exit-ips-tunnels"
category: "Anonymizing Infrastructure"
product: "context-api"
publishedAt: "2026-09-04T00:00:00.000Z"
updatedAt: "2026-09-04T12:03:34Z"
---

# Entrance IPs vs. Exit IPs for Anonymizing Tunnels

Some anonymizing tunnel configurations route through shared infrastructure, like Cloudflare, before reaching the tunnel operator's own exit point. Here's why blocking the entrance IP can affect unrelated legitimate traffic, and what to enforce on instead.

Some anonymizing tunnel services don't connect directly to their own infrastructure. Instead, they route through a shared reverse-proxy network first, then direct the connection to the tunnel operator using separate SNI and Host header values. Because that shared infrastructure also hosts many unrelated websites and services, the same IP address that acts as a tunnel entrance point can also carry entirely legitimate traffic.

This means an IP identified only as a tunnel entrance point isn't, on its own, a reliable signal for blocking. Enforcing on it risks disrupting legitimate traffic that happens to share the same infrastructure.

Spur's tunnel data distinguishes the entrance point from the actual exit — the IP where the tunneled traffic really emerges. When tunnels[].exits is present in the response, use the listed exit IP(s) for enforcement decisions instead of the entrance IP. This targets the tunnel operator specifically and avoids collateral impact on shared infrastructure.