Proxy gateway routing is the process that determines how an incoming proxy connection is mapped to an appropriate exit node before traffic reaches its destination. Although users often interact with a proxy service through a single hostname and port, the infrastructure behind that endpoint can contain many gateways, routing services, geographic pools, session mappings, and exit nodes.

A user may configure an application with something as simple as:

proxy.example.com:8000

but the actual network path can be much more complex:

Application
     ↓
Proxy Hostname
     ↓
Gateway Cluster
     ↓
Authentication
     ↓
Routing Engine
     ↓
Eligible Exit Pool
     ↓
Exit Node
     ↓
Destination

This architecture explains an important characteristic of modern proxy networks:

The proxy server an application connects to is not necessarily the IP address that the destination website sees.

The gateway is an entry point into the proxy network. The exit node is the point from which traffic reaches the destination.

Understanding what happens between those two points is essential for understanding proxy rotation, geographic targeting, sticky sessions, load distribution, and large-scale proxy infrastructure.

---

What Is Proxy Gateway Routing?

Proxy gateway routing determines where traffic should leave a proxy network after the client connects to its entry infrastructure.

Consider a basic proxy configuration:

Host: proxy.example.com
Port: 8000
Username: user
Password: password

The application connects to the gateway:

Client
   ↓
proxy.example.com:8000

But the gateway does not necessarily represent the final internet-facing IP.

Instead, the request can be forwarded through another node:

Client
   ↓
Gateway
   ↓
Exit Node
   ↓
Website

The destination therefore sees:

Exit Node IP

rather than necessarily seeing:

Gateway IP

This separation between entry infrastructure and exit infrastructure is one of the fundamental concepts behind scalable proxy networks.

---

Gateway IP and Exit IP Serve Different Purposes

A gateway IP exists primarily to accept proxy connections.

An exit IP exists to send traffic toward the destination.

Conceptually:

Client
   |
   | connects to
   v
Gateway IP
   |
   | routes through
   v
Exit IP
   |
   | connects to
   v
Destination

These addresses can have completely different network characteristics.

For example:

Gateway
ASN: Hosting Network
Location: Singapore

Exit
ASN: Consumer ISP
Location: Japan

This is not inherently contradictory.

The gateway provides access to the proxy infrastructure, while the exit determines the public network identity observed by the destination.

That is why running DNS lookup tools against a proxy hostname does not necessarily reveal the exit IP that will be used for a request.

---

Why Proxy Networks Use Gateways

A simple proxy system could theoretically expose every proxy node directly:

203.0.113.10:8000
203.0.113.11:8000
203.0.113.12:8000
203.0.113.13:8000

But this becomes difficult to manage when the network contains large and dynamic pools of endpoints.

A gateway creates an abstraction layer.

Instead of the application managing individual nodes:

Application
   ↓
Thousands of Proxy IPs

it can connect to:

Application
   ↓
One Gateway
   ↓
Routing System
   ↓
Many Exit Nodes

This allows routing decisions to happen inside the proxy infrastructure.

The application can specify what type of route it needs while the provider decides which currently eligible exit can satisfy that request.

---

DNS Usually Comes Before the Gateway Connection

When the proxy is configured using a hostname:

proxy.example.com

the client first needs to resolve that hostname.

Conceptually:

proxy.example.com
        ↓
DNS
        ↓
Gateway IP

For example:

proxy.example.com
        ↓
198.51.100.10

The client then establishes a network connection to that gateway.

But large proxy services do not necessarily map one hostname permanently to one server.

DNS could return different gateway addresses:

proxy.example.com
      ↓
198.51.100.10
198.51.100.11
198.51.100.12

This creates another important distinction:

Proxy Hostname
      ≠
One Permanent Gateway

and:

Gateway
      ≠
Exit Node

A single proxy hostname can therefore represent access to a distributed infrastructure.

---

The Gateway Must Authenticate the Client

Before selecting an exit node, the proxy gateway usually needs to determine whether the connection is authorized.

Common authentication methods include:

Username + Password

or:

IP Allowlisting

A simplified sequence looks like:

Client
   ↓
Gateway
   ↓
Authentication
   ↓
Authorized?

If authentication fails:

Connection
   ↓
Rejected

For HTTP proxies, authentication failures can appear as:

407 Proxy Authentication Required

If authentication succeeds, the request can continue into the routing layer.

---

Proxy Credentials Can Carry Routing Instructions

In many proxy systems, credentials do more than identify the account.

The username itself can encode routing parameters.

Conceptually:

customer-user-country-jp-session-abc

could communicate several pieces of information:

Account
   ↓
Country = Japan
   ↓
Session = abc

Another connection might specify:

customer-user-country-de-session-xyz

which expresses a different routing request.

The gateway can parse these parameters before selecting an exit node.

Conceptually:

Incoming Connection
        ↓
Parse Credentials
        ↓
Account
Country
Region
Session
Proxy Type
        ↓
Routing Engine

This is one reason proxy credentials sometimes appear more complicated than ordinary website usernames.

They can function partly as a compact routing configuration.

---

Routing Begins by Building an Eligible Exit Pool

Imagine a proxy network containing many active exit nodes:

Exit A
Exit B
Exit C
Exit D
Exit E
Exit F
...

The routing system generally should not select randomly from the entire global network.

Instead, it first needs to determine which exits satisfy the request.

Suppose the client requests:

Country = Japan
Type = Residential

The routing process becomes:

All Active Exits
       ↓
Residential Exits
       ↓
Japan Exits
       ↓
Eligible Pool

If the user also requests a city:

All Active Exits
       ↓
Residential
       ↓
Japan
       ↓
Tokyo
       ↓
Eligible Pool

The more constraints a request contains, the smaller the candidate pool can become.

---

Exit Selection Is a Filtering Problem Before It Is a Rotation Problem

Proxy rotation is often described simply as:

Pick another IP

But a more accurate model is:

Discover Eligible Nodes
        ↓
Filter Invalid Candidates
        ↓
Apply Session Rules
        ↓
Apply Routing Policy
        ↓
Select Exit

The routing system may need to consider attributes such as:

Country
Region
City
ASN
ISP
Proxy type
Protocol capability
Node availability
Session state

Only after constructing an eligible set does actual selection make sense.

This is why a proxy network cannot necessarily rotate to every IP in its global pool for every request.

The exit must satisfy the request’s routing constraints.

---

Node Health Must Be Part of Proxy Gateway Routing

Suppose three exits satisfy the requested location:

Exit A
Exit B
Exit C

But their current states are:

Exit A → Healthy
Exit B → Offline
Exit C → Degraded

A routing system should not treat all three identically.

A simplified routing pipeline might therefore look like:

Location Filter
      ↓
Eligible Nodes
      ↓
Health Filter
      ↓
Healthy Candidates
      ↓
Exit Selection

Health information can come from different signals depending on the infrastructure.

Examples might include:

Recent connection results
Node availability
Timeout observations
Gateway feedback
Active health checks

The purpose is to avoid repeatedly assigning traffic to nodes known to be unavailable.

---

Active and Passive Health Signals Are Different

Proxy infrastructure can learn about node health in at least two broad ways.

Active health checking

The system intentionally tests a node:

Health Service
     ↓
Exit Node
     ↓
Test Connectivity
     ↓
Record Result

Passive health observation

The system learns from production traffic:

Real Request
     ↓
Exit Node
     ↓
Success / Failure
     ↓
Routing Telemetry

Active tests provide controlled measurements.

Passive signals reveal how nodes behave under actual workloads.

A sophisticated routing system can use both.

However, a node that fails against one destination should not necessarily be classified as globally unavailable.

The failure could exist farther downstream.

This leads to another important distinction:

Node Health
      ≠
Target-Specific Reachability

---

Proxy Routing Needs Failure Classification

Suppose:

Gateway
   ↓
Exit Node
   ↓
Destination

and the request fails.

Where did it fail?

Possible locations include:

Client → Gateway
Gateway Authentication
Gateway → Exit
Exit Network
DNS
Exit → Destination
TLS
Destination Server

A routing system that treats every failure as:

Bad Exit IP

can make poor decisions.

For example, if the destination itself is temporarily unavailable, removing healthy exits from the routing pool would not solve the problem.

A better system distinguishes failure domains before updating routing state.

---

Rotating Sessions and Sticky Sessions Use the Same Pool Differently

Consider an eligible pool:

A
B
C
D
E

A rotating configuration might produce:

Request 1 → B
Request 2 → E
Request 3 → A
Request 4 → D

A sticky session behaves differently.

Suppose:

Session = ABC

is mapped to:

Exit C

Then:

Session ABC
    ↓
Exit C

can be reused for subsequent requests while the mapping remains valid.

The routing engine therefore needs some form of session state:

Session ID
     ↓
Routing Mapping
     ↓
Exit Node

This turns exit selection from a purely stateless process into a stateful one.

---

Sticky Sessions Need a Mapping Lifecycle

A session mapping cannot necessarily exist forever.

A conceptual session record might contain:

Session ID
Exit Node
Created At
Last Used
Expiration
Status

For example:

{
  "session_id": "abc123",
  "exit_node": "node-4821",
  "created_at": "10:00:00",
  "last_used": "10:04:21",
  "expires_at": "10:10:00"
}

When another request arrives:

session=abc123

the routing system can check:

Does mapping exist?
       ↓
Is it still valid?
       ↓
Is exit still available?

If all conditions are satisfied, the route can be reused.

If not, another routing decision may be required.

---

What Happens When a Sticky Exit Goes Offline?

This is one of the more difficult routing problems.

Suppose:

Session ABC
      ↓
Exit Node A

Then Node A disappears.

The routing system now faces a trade-off.

It can:

Fail the request

or potentially:

Select another eligible exit

depending on the proxy architecture and session policy.

If another exit is selected:

Session ABC
      ↓
Exit Node B

the session identifier remains the same, but the public IP can change.

This demonstrates why:

Sticky Session
      ≠
Permanent IP Guarantee

A sticky session describes a routing preference or mapping behavior, while the underlying node remains dependent on network availability.

---

Routing Decisions Can Happen at Different Times

Another subtle issue is when the exit is selected.

Possible architectures include selection:

When proxy connection is established

or:

When a new HTTP request arrives

or:

When a session is created

These models can produce different observable behavior.

Consider HTTP Keep-Alive.

If exit selection occurs once per proxy connection:

TCP Connection
      ↓
Exit A
      ↓
Request 1
Request 2
Request 3

connection reuse may also preserve the route.

If routing occurs independently at another layer, the behavior can differ.

This is why proxy rotation cannot be understood only by counting HTTP requests.

The routing boundary matters.

---

Proxy Gateways Need Load Distribution

Even after filtering, a routing system may still have thousands of eligible exits.

It must decide how traffic should be distributed.

A naive system could simply select exits randomly.

But production routing can consider more information.

Conceptually:

Eligible Exit Nodes
        ↓
Routing Policy
        ↓
Load Distribution
        ↓
Selected Exit

Possible considerations can include:

Current availability
Recent utilization
Session bindings
Geographic constraints
Node capacity
Connection state

The exact algorithm varies by network.

The broader principle is that rotation and load balancing are related but not identical.

Rotation concerns which network identity is selected.

Load balancing concerns how work is distributed across infrastructure.

---

Pure Random Selection Can Produce Uneven Distribution

Suppose there are four eligible nodes:

A
B
C
D

Random selection does not guarantee:

25%
25%
25%
25%

over a short observation period.

You might instead observe:

A → 31%
B → 18%
C → 27%
D → 24%

That is normal statistical variation.

At large scale, infrastructure may also intentionally weight nodes differently.

For example:

A → weight 1
B → weight 1
C → weight 2
D → weight 4

Now equal distribution is not even the objective.

This is why users should not assume that every IP in a pool receives equal traffic.

---

Weighted Routing Can Reflect Exit Capacity

Not all exit nodes necessarily have identical characteristics.

A routing system might model capacity conceptually as:

Exit A → Capacity 1
Exit B → Capacity 2
Exit C → Capacity 5

Then traffic can be distributed accordingly.

A simplified probability model could be:$$P(i)=\frac{w_i}{\sum_j w_j}$$

where $w_i$ is the routing weight assigned to exit $i$.

If:

A = 1
B = 2
C = 5

the total weight is:

8

and C would receive a larger share of selection opportunities.

Real routing systems can be considerably more complex, but this illustrates why proxy load balancing should not be assumed to be simple round-robin rotation.

---

Gateway Capacity and Exit Capacity Are Different

Another important distinction is:

Gateway Capacity
       ≠
Exit Pool Capacity

A gateway might be capable of accepting a large number of connections while only a smaller number of eligible exits exist for a particular location.

Conversely, a network might have many available exits but insufficient gateway capacity for a sudden connection spike.

The infrastructure contains separate scaling domains:

Client Connections
       ↓
Gateway Capacity
       ↓
Routing Capacity
       ↓
Exit Capacity
       ↓
Upstream Network
       ↓
Destination

A bottleneck can occur at any one of these layers.

This is why proxy scalability cannot be inferred solely from IP pool size.

---

Large Proxy Networks Usually Need Multiple Gateways

A single gateway creates an obvious concentration point.

Large-scale architectures can instead distribute entry traffic across gateway clusters.

Conceptually:

                   ┌→ Gateway A ─┐
Client → DNS / LB ─┼→ Gateway B ─┼→ Routing Layer → Exit Pool
                   └→ Gateway C ─┘

This architecture can provide several benefits:

Horizontal scaling
Fault isolation
Regional entry points
Maintenance flexibility
Traffic distribution

If one gateway becomes unavailable, other gateways can continue accepting connections if the surrounding architecture supports failover.

The proxy hostname therefore acts as an abstraction over the gateway infrastructure itself.

---

Regional Gateways Can Reduce the Client-to-Proxy Path

Imagine a user in Asia connecting to a gateway physically located in Europe before traffic exits again in Asia.

The path might look like:

Asia Client
     ↓
Europe Gateway
     ↓
Asia Exit
     ↓
Asia Destination

A regional gateway architecture could instead provide:

Asia Client
     ↓
Asia Gateway
     ↓
Asia Exit
     ↓
Asia Destination

This does not automatically determine total request performance because internet routing and destination networks also matter.

But it demonstrates that the gateway’s location and the exit’s location are two separate geographic variables.

When measuring proxy routes, it can therefore be useful to distinguish:

Client → Gateway Latency

from:

Gateway / Exit → Destination Latency

rather than treating everything as one generic proxy latency number.

---

Geographic Targeting Happens Before Exit Selection

Suppose a user requests Japan.

A simplistic model might be:

Choose random IP
      ↓
Check whether it is in Japan

That would be inefficient.

A better architecture maintains metadata associated with exit nodes.

Conceptually:

Node 1821
Country: JP
Region: Tokyo
ASN: ASxxxx
Type: Residential
Status: Healthy

The routing system can query eligible candidates directly:

country = JP
AND
type = residential
AND
status = healthy

Then select from the resulting pool.

This turns geographic routing into a metadata-driven selection problem.

---

Exit Metadata Must Stay Fresh

The routing engine depends on metadata.

If metadata becomes stale, routing quality can degrade.

For example:

Database:
Node A → Japan

but the endpoint’s network has changed and current observations suggest something different.

The routing layer could continue making incorrect assignments until its information is updated.

Relevant metadata can include:

Current public IP
Country
Region
ASN
ISP
Protocol capability
Availability
Last seen

Dynamic residential networks make freshness particularly important because endpoints and network addresses can change over time.

This creates a feedback loop:

Exit Observation
      ↓
Metadata Update
      ↓
Routing Decision
      ↓
Traffic
      ↓
New Observation

Routing is therefore not only about selecting nodes. It also depends on continuously maintaining an accurate view of the network.

---

Proxy Routing Tables Are Different From Internet Routing Tables

The term “routing” can cause confusion here.

Internet routing protocols such as BGP determine how packets move between autonomous systems.

A proxy routing engine makes an application-level decision about which proxy exit should handle a connection or request.

These are different layers.

Proxy Routing
→ Which exit node should we use?

Then:

Internet Routing
→ How do packets travel from that exit to the destination?

The complete path therefore looks like:

Client
   ↓
Proxy Routing Decision
   ↓
Selected Exit
   ↓
Internet Routing
   ↓
Destination

A proxy provider controls the first decision much more directly than the second.

Once traffic leaves the exit network, normal internet routing becomes part of the path.

---

Why Two Requests Through the Same Gateway Can Take Different Routes

Consider:

Request A
Request B

Both connect to:

proxy.example.com:8000

But the routing system selects:

Request A
    ↓
Gateway
    ↓
Exit A
    ↓
ISP A
    ↓
Destination

and:

Request B
    ↓
Gateway
    ↓
Exit B
    ↓
ISP B
    ↓
Destination

The requests therefore share the same entry infrastructure but diverge inside the proxy network.

They may consequently have different:

Exit IPs
ASNs
ISPs
Network paths
Latency
Geographic metadata

This explains why the gateway address alone cannot describe the complete route.

---

Why the Same Exit IP Can Still Produce Different Network Conditions

Even if two requests use the same exit IP, their performance does not have to be identical.

The downstream internet path can change because of:

Routing changes
Network congestion
Destination CDN behavior
Peering
Transit conditions
Server load

Therefore:

Same Exit IP
      ≠
Identical Request Path

The proxy routing decision controls which exit is selected.

It does not freeze the rest of the internet.

This distinction becomes important when debugging variable latency or intermittent destination failures.

---

Failover Is Different From Rotation

These terms are also easy to confuse.

Rotation deliberately selects another exit according to routing policy.

Exit A
  ↓
Exit B

Failover changes the route because the preferred path is no longer usable.

Exit A
  ↓
Failure
  ↓
Exit B

Both can result in a different public IP.

But the reason is different.

This matters particularly for sticky sessions.

A user might interpret an unexpected IP change as normal rotation when it was actually triggered by an exit failure.

Observability should therefore record the reason for route changes where possible.

---

Routing Decisions Should Be Observable

A proxy system becomes much easier to operate when routing decisions produce structured telemetry.

A routing record might conceptually contain:

{
  "request_id": "req-18420",
  "gateway": "gateway-ap-02",
  "requested_country": "JP",
  "session_id": "abc123",
  "selected_exit": "node-4721",
  "exit_ip": "203.0.113.x",
  "asn": "AS64500",
  "selection_reason": "sticky_session",
  "timestamp": "2026-09-24T10:20:00Z"
}

This allows engineers to answer questions such as:

Why was this exit selected?

Did the session mapping work?

Was the requested country satisfied?

Did failover occur?

Which gateway handled the connection?

How frequently is each exit selected?

Without this information, routing problems can look like random proxy failures.

---

Measure Exit Selection Distribution

Routing quality can also be analyzed statistically.

Suppose 100,000 requests are sent through one geographic pool.

Record:

Requests per Exit
Requests per ASN
Requests per ISP
Session Assignments
Route Changes
Failovers

Then examine concentration.

For example:

Top 1% of exits
→ 35% of traffic

could indicate significant traffic concentration.

Whether that is desirable depends on the routing policy.

The important point is that a proxy pool containing many addresses does not automatically mean traffic is evenly distributed across them.

Routing policy determines actual utilization.

---

Measure Routing Decision Latency Separately

Proxy gateway processing itself can introduce latency.

A request might involve:

Authentication
       ↓
Credential Parsing
       ↓
Session Lookup
       ↓
Candidate Filtering
       ↓
Exit Selection
       ↓
Connection Establishment

These operations should be fast in a well-designed system, but they still represent a distinct part of the request lifecycle.

A useful internal benchmark separates:

Gateway Accept Time
Authentication Time
Routing Decision Time
Exit Connection Time
Destination Response Time

This makes it possible to distinguish slow routing logic from slow exit connectivity or slow target responses.

---

What Happens When No Eligible Exit Exists?

This is an important edge case.

Suppose the request requires:

Country = X
City = Y
ISP = Z

but currently:

Eligible Exit Count = 0

The routing system has several possible policy choices.

It might:

Fail immediately

or:

Wait for capacity

or, only if the product explicitly allows it:

Relax a targeting constraint

Silently routing through an unrelated location can be problematic because the application may assume the requested geography was satisfied.

A robust design therefore needs an explicit policy for empty candidate pools.

---

Why Retry Logic Should Not Blindly Repeat the Same Route

Suppose:

Request
   ↓
Exit A
   ↓
Connection Failure

A naive retry immediately sends:

Retry
   ↓
Exit A

again.

If the problem is associated with Exit A, the retry provides little value.

A routing-aware retry system can potentially use failure context to decide whether another eligible route should be selected.

Conceptually:

Failure
   ↓
Classify Error
   ↓
Is route-specific?
   ↓
Yes
   ↓
Select another eligible exit

But if the destination itself is unavailable, changing exits may simply waste resources.

This is why error classification and routing policy need to work together.

---

Where ColaProxy Fits Into Proxy Gateway Routing

For proxy infrastructure such as ColaProxy, the gateway can be understood as the stable access layer between the application and the available proxy network.

A typical workflow is:

Application
     ↓
ColaProxy Gateway
     ↓
Authentication / Routing Parameters
     ↓
Eligible Proxy Pool
     ↓
Exit Selection
     ↓
Destination

For permitted automation and data collection, developers can use routing requirements such as geography and session behavior according to the needs of the application.

The important architectural distinction is that the gateway and exit serve different purposes.

The application does not need to manually maintain a list of every possible exit node. Instead, the gateway provides an abstraction through which eligible exits can be selected according to the requested configuration and current network state.

When diagnosing behavior, developers should therefore examine both sides:

Gateway Connection

and:

Observed Exit

rather than assuming they represent the same network endpoint.

---

A Better Mental Model for Proxy Gateways

The easiest way to understand a modern proxy gateway is not as:

One Proxy Server

but as:

Access Layer
     +
Authentication Layer
     +
Routing Layer
     +
Session Layer
     +
Exit Selection Layer

Conceptually:

                 Proxy Network
┌─────────────────────────────────────┐
│                                     │
│ Client                              │
│   ↓                                 │
│ Gateway                             │
│   ↓                                 │
│ Authentication                      │
│   ↓                                 │
│ Routing Engine                      │
│   ↓                                 │
│ Candidate Filtering                 │
│   ↓                                 │
│ Session / Load Policy               │
│   ↓                                 │
│ Exit Selection                      │
│   ↓                                 │
│ Exit Node                           │
│                                     │
└─────────────────────────────────────┘
              ↓
          Internet
              ↓
        Destination

This model explains several behaviors that otherwise appear confusing:

Same proxy hostname
→ Different exit IPs

Same session
→ Same exit for multiple connections

Exit failure
→ Possible route change

Different country parameter
→ Different eligible pool

Same gateway
→ Different ASNs and ISPs

Once the gateway is understood as a routing layer rather than simply another IP address, these behaviors become much easier to reason about.

---

Conclusion

Proxy gateway routing is the infrastructure layer that connects a simple proxy configuration to a potentially large and dynamic network of exit nodes.

The user may only see:

proxy.example.com:8000

but behind that endpoint, the system may need to perform:

Authentication
       ↓
Parameter Parsing
       ↓
Geographic Filtering
       ↓
Session Lookup
       ↓
Health Filtering
       ↓
Load Distribution
       ↓
Exit Selection

The selected exit then becomes the network identity visible to the destination.

This is why the gateway IP and exit IP should not be treated as the same thing, and why proxy rotation involves much more than randomly changing an address.

A scalable proxy network must continuously answer a more complex question:

Which currently available exit node best satisfies the routing requirements of this connection?

That decision sits at the center of modern proxy gateway architecture.

---

Frequently Asked Questions

What is a proxy gateway?

A proxy gateway is an entry point through which clients connect to a proxy network. It can authenticate connections, interpret routing parameters, apply session rules, and direct traffic toward eligible exit nodes.

Is a proxy gateway the same as an exit proxy?

Not necessarily. The gateway accepts the client’s connection, while the exit node is the network endpoint that connects toward the destination. They can have different IP addresses, ASNs, and locations.

Why does one proxy hostname produce different IP addresses?

A proxy hostname can point to gateway infrastructure that routes different connections or sessions through different exit nodes. The hostname remains stable while the selected exit can change.

How does a proxy gateway choose an exit IP?

The exact implementation varies, but routing can consider requirements such as geography, proxy type, session state, node availability, and load distribution before selecting an eligible exit.

How do sticky sessions work with a proxy gateway?

A routing system can associate a session identifier with an exit node and attempt to reuse that mapping while it remains valid and the selected exit remains available.

Why can a sticky proxy session change IP?

The underlying exit can become unavailable, its public IP can change, or the session mapping can expire. Sticky routing therefore should not automatically be interpreted as a permanent-IP guarantee.

Is proxy rotation the same as load balancing?

No. Rotation concerns changing or selecting exit identities. Load balancing concerns distributing workload across infrastructure. A proxy routing system may use both.

Does the location of the gateway determine the proxy location?

Not necessarily. The gateway and exit are separate network components. The destination normally observes the exit network, while the gateway can be located elsewhere.