Proxies and Gateways: The Middlemen That Quietly Route Your Traffic

Imagine you want to send a letter, but instead of dropping it in the mailbox yourself, you hand it to an assistant who addresses it, stamps it, and posts it for you — and when a reply comes back, it lands on the assistant’s desk first, gets checked, and only then reaches you. That assistant is a proxy. Now imagine your office is in one country and the recipient is in another, with different postal rules, different forms, a different language on the envelope. Something at the border has to translate and forward your mail into a format the other side understands. That something is a gateway.

Both words get thrown around constantly in networking, often as if they mean the same thing. They don’t — and the difference is genuinely useful once it clicks. A proxy is a stand-in that handles requests on your behalf. A gateway is a doorway between two different worlds. This article untangles the two, walks through the kinds you’ll actually meet, and shows where each one sits in the path your traffic takes.

What a proxy actually is

A proxy is a server that sits in the middle of a conversation and acts on behalf of one side. Instead of a client talking directly to a destination, it talks to the proxy, and the proxy passes the request along, gets the response, and hands it back.

That single layer of indirection turns out to be enormously powerful. Because every request and response flows through the proxy, the proxy can inspect it, change it, cache it, block it, log it, or redirect it. It’s a checkpoint you get to control, sitting right in the flow of traffic.

The key thing to hold onto: a proxy doesn’t originate the conversation, and it isn’t the final destination either. It stands in the middle, representing one party to the other. Which party it represents is exactly what splits proxies into two big families.

   without a proxy
   CLIENT  ───────────────────────────►  DESTINATION

   with a proxy
   CLIENT  ─────►  PROXY  ─────►  DESTINATION
                     │
              inspect / cache / filter / log

Forward proxy: standing in for the client

A forward proxy sits in front of the clients. The people (or machines) on the inside send their requests to the proxy, and the proxy reaches out to the wider internet for them. To the outside world, the request looks like it came from the proxy, not from the original client.

This is the kind of proxy a company puts at the edge of its office network. Every employee’s browser is configured to go through it, and that gives the company a single place to enforce rules:

• Filtering — block certain websites, scan for malware, stop data from leaking out.
• Privacy / anonymity — hide the real client’s IP address; the destination only sees the proxy.
• Caching — if a hundred employees request the same file, the proxy can fetch it once and serve the cached copy to the rest, saving bandwidth.
• Logging and policy — record who went where, and apply access rules in one spot.

A VPN is a close cousin of this idea, and so is the kind of “proxy server” people use to reach content that’s region-locked. In all of these, the proxy speaks for the client.

   FORWARD PROXY  (stands in for the CLIENTS)

   client A ─┐
   client B ─┼──►  FORWARD PROXY  ─────►  the internet
   client C ─┘        (one exit)

Reverse proxy: standing in for the server

Flip it around and you get a reverse proxy. This one sits in front of the servers. Clients out on the internet send their requests to the reverse proxy, and it decides which backend server should handle each one, fetches the response, and returns it. To the client, the reverse proxy is the website — they never see the machines behind it.

This is the workhorse of modern web infrastructure. A reverse proxy is where HTTPS gets terminated, where traffic gets spread across several backend servers, where caching and compression happen, and where one domain can quietly fan out to many different services. It’s such a central concept that it deserves its own treatment — if you want the full picture, read our guide to reverse proxies, and the closely related idea of load balancing.

   REVERSE PROXY  (stands in for the SERVERS)

                          ┌──►  app server 1
   client ──►  REVERSE ───┼──►  app server 2
              PROXY       └──►  app server 3
            (one entrance)

What a gateway actually is

A gateway is a different beast. Where a proxy passes traffic along (same network, same kind of protocol, just relayed through a middleman), a gateway sits between two different networks or two different protocols and translates between them. It’s a doorway, and crossing it means being converted into whatever language lives on the other side.

The most familiar example is sitting in your home right now. Your default gateway is the router that connects your local home network to the internet. Your laptop, phone, and TV all share a private network at home; none of them can talk to the wider internet directly. They hand their traffic to the gateway, which forwards it out and translates the addressing (this is part of what NAT does) so the reply finds its way back. Every device has a “default gateway” setting for exactly this reason: it’s the exit door to everywhere else.

Gateways show up wherever two systems that don’t naturally understand each other need to talk:

• A network gateway / router — joins your local network to the internet (your home router).
• An API gateway — a single entry point in front of many backend services, often translating, authenticating, and rate-limiting requests before passing them deeper in.
• A payment gateway — bridges an online store and the banking networks that actually move money.
• An email gateway — sits between your mail system and the outside world, filtering spam and enforcing policy.
• A protocol gateway — converts between two protocols entirely, like turning messages from an old industrial system into something a modern app can read.

The unifying idea: a gateway is the point where traffic crosses a boundary and may be transformed to fit the other side.

   GATEWAY  (the doorway between two different worlds)

   home network  ──►  GATEWAY  ──►  the internet
   (private IPs)      (router /     (public IPs,
                       translates)   different rules)

Proxy vs gateway: the part everyone mixes up

Here’s the honest truth: the line between a proxy and a gateway is blurry in practice, and you’ll hear the words used loosely. But the intent behind each is different, and that’s what matters.

A reverse proxy and an API gateway, in particular, overlap so much that products are often sold as both. The rough distinction: a reverse proxy mainly routes and forwards the same kind of web traffic, while an API gateway adds a layer of understanding the requests — authentication, rate limiting, request shaping, stitching several services together. If something just relays traffic, lean toward calling it a proxy; if it crosses a boundary and transforms or governs the traffic, lean toward gateway.

Where they sit in the path of a request

It helps to see how these middlemen stack up in a single, realistic journey. Picture an employee at ACY Partner Indonesia opening a website from the office:

  [browser]
      │   request leaves the laptop
      ▼
  [FORWARD PROXY]   ← company's outbound filter / cache
      │   exits the office network through the…
      ▼
  [GATEWAY / router]   ← doorway from the office LAN to the internet
      │   travels across the internet to the website
      ▼
  [REVERSE PROXY]   ← the website's front door (HTTPS, routing)
      │   handed to the right backend
      ▼
  [app server]   ← actually builds the response

One request, and it may pass through a forward proxy, a gateway, and a reverse proxy before anything real happens — and then the response retraces the whole path back. None of these are visible to the person who just typed a URL, which is exactly the point. They do their work quietly, in the gaps between the obvious pieces.

Why this matters

You don’t have to configure any of this to benefit from understanding it. Knowing the difference between a proxy and a gateway pays off the moment you start reading real-world infrastructure diagrams, debugging why a request “looks like it came from somewhere else,” or choosing tools for your own setup.

• When a destination logs the wrong IP address, a forward proxy or your gateway’s address translation is usually why.
• When one domain quietly serves many services behind it, a reverse proxy is doing the routing.
• When your devices can’t reach the internet, a misconfigured default gateway is one of the first things to check.
• When you build an app made of several services, an API gateway is often how you give the outside world a single, sane front door.

These pieces are the connective tissue of every network. They sit in the spaces between the obvious parts — between you and the internet, between the internet and a website, between one service and the next — and they decide what gets through, where it goes, and what shape it arrives in. Filtering rules that depend on them, like firewalls, make a lot more sense once you can see the middlemen they sit alongside.

Wrapping up

Here’s the whole picture in one place:

• A proxy is a stand-in that relays requests on someone’s behalf. It doesn’t originate or finally receive the traffic — it sits in the middle and can inspect, cache, filter, or log everything that passes.
• A forward proxy represents the clients behind it (a company’s outbound proxy). A reverse proxy represents the servers behind it (a website’s front door).
• A gateway is a doorway between two different networks or protocols, and it often translates traffic to fit the other side. Your home router is the classic example; API gateways and payment gateways are others.
• Proxy vs gateway: a proxy relays the same kind of traffic; a gateway bridges and transforms across a boundary. In real systems the roles blur, so focus on behavior, not the label.
• A single request can pass through a forward proxy, a gateway, and a reverse proxy before reaching the server that actually answers it.

Next, it’s worth going one layer deeper into the system that turns human-friendly names into the addresses all of this routing relies on — a proper look at how DNS really works under the hood.