What is Reverse Proxy?

A reverse proxy is a server that receives requests on behalf of one or more applications, forwards eligible requests to the appropriate backend and returns the response to the client. Your browser connects to the proxy as the website’s public endpoint. The application behind it can use a different address, port or protocol. This lets you give several services a consistent entry point and manage routing and HTTPS centrally.

A reverse proxy works on the service side of the connection. A forward proxy acts on behalf of clients accessing other services. Neither name means that packets travel backwards. For a UK home lab, the useful distinction is between making a request reach your network and deciding which application handles it once it arrives.

How does a reverse proxy work?

Consider an illustrative HTTPS request for photos.example.com. DNS directs the browser towards the public endpoint. In a conventional HTTP reverse proxy deployment, the proxy handles the client connection and communicates separately with the backend. Connections can be reused; a new browser request does not necessarily create a new backend connection.

1. The browser resolves the hostname and connects to the proxy endpoint.

2. For HTTPS, the client validates the endpoint’s certificate and negotiates TLS before sending the HTTP request.

3. The proxy examines the hostname, path or other configured request information and selects a backend.

4. It sends an appropriate request to that backend over a separate connection.

5. The application produces a response, which the proxy relays to the browser. A configured cache may instead satisfy an eligible request without contacting the application.

The browser normally keeps the same public URL. The proxy can change the internal destination without redirecting the user. A redirect is different: it tells the browser to make another request to a specified location.

The terminology follows RFC 9110, section 3.7, the 2022 HTTP Semantics Internet Standard, which calls this intermediary a gateway or reverse proxy.

The infographic shows the two connections separately. HTTPS on the public side does not determine whether the backend side uses HTTP or HTTPS.

Hostname routing, path routing and TLS passthrough

Hostname routing can send photos.example.com to a photo application and status.example.com to a monitoring service while both names use the same public IP address and HTTPS port. With HTTP/1.1, the Host header identifies the requested host; HTTP/2 and HTTP/3 use the corresponding authority information. The application can still need its own public URL and proxy awareness configured.

Path routing can send /api/ to one backend and the rest of a site to another. Applications must support their assigned path prefix, including generated links, redirects, cookies and static assets. Separate hostnames are often simpler for applications that assume they run at the root.

TLS passthrough forwards encrypted transport traffic without decrypting HTTP at the proxy. That prevents ordinary HTTP path inspection there. Some products can select a backend using an available TLS Server Name Indication value. RFC 6066, section 3 defines SNI, which identifies a server name rather than a URL path.

DNS, TLS and HTTP routing therefore solve different parts of the request. Pointing a hostname at the right address does not configure the certificate, and a valid certificate does not prove that the correct application receives the request.

Reverse proxy vs forward proxy, port forwarding and load balancer

Component	Main job	What it does not establish
Reverse proxy	Receives service requests and routes them to backends.	Internet reachability or secure application behaviour.
Forward proxy	Makes requests on behalf of configured clients.	A public entry point for your home applications.
Port forwarding	Maps incoming traffic to an internal address and port.	HTTP hostname or path routing by itself.
Load balancer	Distributes traffic among eligible backends.	Unlimited capacity or complete fault tolerance.
VPN	Provides an authorised network tunnel or private access path.	Automatic application routing or public hosting.
CDN	Uses distributed infrastructure, often with caching and proxying.	A guaranteed cache hit or healthy origin.

These functions can coexist. Port forwarding can deliver traffic to a home reverse proxy, which then routes it to an application. A reverse proxy can serve just one backend; load balancing is an additional function when multiple eligible backends are available.

HTTPS termination: check both connections

TLS termination means the proxy decrypts the client’s HTTPS traffic so it can process HTTP. It then contacts the application using its configured transport. The browser’s secure connection is with the proxy, which can see the HTTP content at this point.

• HTTPS to proxy, HTTP to backend: the backend leg is unencrypted. Decide whether that fits the network’s trust boundary.

• HTTPS to proxy, HTTPS to backend: both legs are encrypted, but they are separate sessions.

• TLS passthrough: the backend handles the client TLS session; the proxy has less HTTP visibility.

Encryption and authentication are separate checks. For an HTTPS backend, configure trusted certificate authorities, hostname verification and the expected server name. NGINX documents upstream certificate verification as disabled by default; simply changing proxy_pass to an HTTPS URL does not turn verification on.

A managed edge introduces another trust boundary. For example, Cloudflare documents certificate validation in Full (strict) mode. Check the exact product and configuration rather than assuming every service labelled HTTPS behaves identically.

Client IP addresses and trusted proxy headers

The backend usually sees the proxy as its immediate network peer. Headers can communicate the original client address and public scheme. RFC 7239, a 2014 Proposed Standard, defines Forwarded parameters including for, host and proto. Widely used X-Forwarded headers provide related information.

These values are metadata, not proof of identity. A client can send its own header values. Restrict which proxies the application trusts, sanitise incoming values at the appropriate boundary and prevent direct backend access that bypasses that policy.

NGINX’s real IP module lets administrators specify trusted senders and the address header to interpret. If a CDN precedes your proxy, account for that additional hop and its documented header rules. Never trust every address simply to make the logs look correct.

Wrong scheme information can create redirect loops: the browser uses HTTPS, the backend sees HTTP and repeatedly asks for HTTPS. Incorrect host information can also produce internal addresses in redirects or broken login cookies. Configure the application’s public origin and trusted proxy settings together.

Can a reverse proxy work behind CGNAT?

An ordinary reverse proxy running at home cannot make unsolicited internet traffic cross your ISP’s CGNAT by itself. It can route a request only after some usable path delivers that request. Changing your own router’s port forwarding does not configure the ISP’s upstream NAT.

RFC 6598, published as Best Current Practice in 2012, reserves 100.64.0.0/10 for shared address space. An address in that range is a useful clue, but address checks alone do not establish every detail of an ISP’s deployment.

Your situation	Possible access design	What to verify
Public IPv4 with inbound access	Router forwards the required service traffic to the proxy.	ISP policy, router rules, host firewall and dynamic DNS if needed.
Usable public IPv6	Clients reach the proxy through IPv6.	Client IPv6 access, DNS AAAA records and explicit firewall permission.
CGNAT without inbound mapping	Outbound tunnel, or a public server connected privately to home.	Tunnel transport, authentication, quotas, service terms and failure behaviour.
Services for you or a small trusted group	Private VPN or overlay access.	Authorised devices, access controls and reliable connectivity.

Cloudflare’s Tunnel documentation describes an outbound connector from your network to its edge. That connector is the additional reachability mechanism. A public server linked to home through a private tunnel is another architecture. Both add operational dependencies and may add latency.

A static address provides address stability; it does not remove firewall requirements or prove inbound ports are allowed. IPv6 can provide a separate reachable path where supported, but an IPv4 only client still needs an appropriate route. Verify the ISP, access network, product and location before choosing a design.

A small Caddy example

This illustrative Caddyfile gives two applications different public hostnames. Replace the example names with domains you control. It assumes Caddy and both applications run on the same host, with the applications listening on the stated loopback ports.

photos.example.com {
    reverse_proxy 127.0.0.1:3000
}

status.example.com {
    reverse_proxy 127.0.0.1:8080
}

Caddy documents automatic HTTPS for qualifying hostnames. Successful public certificate issuance still depends on the configured challenge, DNS and necessary reachability. A DNS challenge can prove domain control without opening inbound ports for that challenge; it does not make the application reachable.

Loopback here refers to Caddy’s own host. 127.0.0.1 on a different machine points to that machine instead. This example is a routing illustration, not a complete deployment: configure authentication, application proxy settings, persistent certificate storage and access policy for your environment.

Reverse proxies and Docker networking

Inside a container, 127.0.0.1 normally means that container’s own network namespace. A proxy container therefore cannot ordinarily reach a separate application container by using the application’s loopback address.

Docker’s networking documentation explains that containers on a user defined network can communicate by container name. A deployment might route to photos:3000 on that shared network, while publishing only the proxy’s intended entry ports. The application must listen on an appropriate container interface.

Check that your Docker networks, published ports and firewall behaviour match the intended exposure. Publishing every backend port can create a route around proxy authentication, even if the public hostname itself works perfectly.

Caching, streaming and connection limits

Caching can reduce backend work for eligible reusable responses. It must respect response policy, cache keys and user separation. Do not cache an authenticated account page as if it were a public asset. RFC 9111 defines HTTP caching rules, including private and no-store directives.

WebSockets and streamed responses need suitable handling throughout the path. NGINX’s WebSocket guide explains explicit forwarding of upgrade information. Caddy documents WebSocket support in its reverse proxy handler. A successful ordinary page request does not prove that a persistent connection will survive timeouts or configuration reloads.

• Large uploads: check request body limits, buffering and application limits.

• Live streams: check response buffering, idle timeouts and intermediary limits.

• Long requests: distinguish connection, read and total application time limits.

• Many users: monitor open connections, file descriptors, memory, CPU and backend capacity.

• Multiple instances: consider health checks, shared sessions and what happens to requests already in flight.

NGINX’s upstream module documents backend groups and selection behaviour. Feature availability differs between products and editions. A single proxy can remain a single point of failure even when several application servers sit behind it.

Techie Broadband analysis: your home upload becomes their download

For a remotely accessed home application, response data leaves your house. Your home upload capacity therefore limits the remote client’s download. A reverse proxy organises that traffic; it does not increase the physical capacity.

Illustrative calculation: assume a decimal 1 GB file, a 100 Mbps remote download, a capable proxy and backend, no competing traffic and no cache hit outside the home. The useful payload contains 8,000 megabits. The ideal minimum time is 8,000 divided by the relevant bottleneck rate.

Home upload	Remote download	Ideal bottleneck ceiling	Ideal 1 GB transfer
20 Mbps	100 Mbps	20 Mbps	400 seconds, or 6 min 40 sec
100 Mbps	100 Mbps	100 Mbps	80 seconds, or 1 min 20 sec
1 Gbps	100 Mbps	100 Mbps	80 seconds, or 1 min 20 sec

These are Techie Broadband calculations, not measurements. Protocol overhead, packet loss, storage, WiFi, encryption, congestion and server limits make real transfers slower. A tunnel or public relay can introduce another ceiling. Three simultaneous 10 Mbps streams need 30 Mbps of payload capacity, so they cannot all sustain that rate across a 20 Mbps home upload.

The complete path includes application and storage, proxy processing, LAN, router, ONT or modem, FTTP or FTTC access, ISP routing, any relay and the client’s network. Compare upload speed and download speed in their actual directions. Bandwidth is capacity, not a guarantee of achieved throughput.

Latency is a separate constraint. A local proxy may add little delay when uncongested; a geographically distant relay may add a meaningful detour. Caching can remove some origin requests, while connection reuse can avoid repeated setup work. There is no universal number of milliseconds that a reverse proxy adds.

How to troubleshoot a reverse proxy

1. Record the hostname, path, timestamp and exact error. Establish whether all services fail or only one route.

2. Check DNS A and AAAA records. Test IPv4 and IPv6 separately if one family works and the other fails.

3. Check endpoint reachability from outside the LAN. A mobile connection can help distinguish public access from local DNS or NAT loopback behaviour.

4. Verify the public certificate and hostname. A connection to a bare IP does not test the same TLS name and HTTP route.

5. From the proxy’s host or container, test the configured backend address and port. Check application logs and listening interfaces.

6. Compare proxy access and error logs with backend logs. Look for connection refusal, certificate failures, timeouts and incorrect routing.

7. Check public URL, forwarded scheme, trusted proxy and cookie settings for redirect or login failures.

8. Test the actual failing workload: a large upload, persistent WebSocket or slow response may need different limits from a small page.

9. Measure proxy CPU, memory, connections and home upload demand before blaming the broadband service.

For a specific HTTPS route, curl’s documented --resolve option lets you override name resolution while keeping the URL hostname for TLS and HTTP. The address below is reserved for documentation; replace it with your own proxy address.

curl --resolve photos.example.com:443:203.0.113.10 https://photos.example.com/

This bypasses the DNS lookup for that host and port. It does not bypass certificate validation, firewalls or CGNAT. Avoid disabling certificate checks to hide the fault you are trying to diagnose.

Symptom	Useful first checks
502 Bad Gateway	Proxy logs, backend response, address, listening port and upstream TLS.
504 Gateway Timeout	Backend response time, configured timeout and the proxy to backend path.
413 Content Too Large	Proxy and application request body limits.
Wrong application or 404	Hostname rule, path rewrite, default route and application base path.
Redirect loop or failed login	Original scheme, public host, trusted headers and cookies.
Works locally, fails remotely	DNS, inbound access, CGNAT, IPv6 and firewalls.

HTTP status codes describe a response, not a complete diagnosis. A proxy generated error and an application generated error can look similar. Check which component issued the response before changing configuration.

Security and maintenance

• Expose only intended services. Keep administrative interfaces private where practical.

• Use application authentication and appropriate additional proxy access checks.

• Restrict backend access so the proxy’s policy cannot be bypassed.

• Protect certificate keys, DNS credentials and configuration backups.

• Keep proxy and applications updated, and review changes before rollout.

• Monitor certificate renewal, errors, resource use and restoration procedures.

• Treat client addresses and request logs as potentially sensitive; avoid unnecessary retention.

A reverse proxy can concentrate useful controls, but it also concentrates responsibility. If its routing is too broad, its credentials leak or its host fails, several services may be affected at once. Rate limits and filtering do not repair vulnerable application code, and a proxy at home cannot prevent a large attack from filling the access link before traffic reaches it.

Frequently asked questions

Do I need a reverse proxy for one application?

Not necessarily. A single application can serve its own HTTPS endpoint. A proxy becomes useful when you want separate routing, certificate handling or access policy. Choose it for a concrete requirement rather than adding a component by default.

Does a reverse proxy hide my home IP?

A proxy hosted directly at home normally uses your home connection’s public endpoint. An external edge can keep that address out of the usual DNS response, but origin exposure elsewhere and direct access rules still matter. It does not make the operator anonymous.

Does it work without internet access?

Yes, for locally reachable applications. Local DNS, certificate trust and network policy still need to work. Public hosting and public certificate renewal may have separate external dependencies.

Can I use one public IP for several services?

Yes. An HTTP reverse proxy can route several hostnames through one endpoint. Those names need appropriate DNS and certificate coverage, and each backend needs the correct routing rule. This does not mean every arbitrary TCP or UDP service can share an HTTP route.

Is a reverse proxy a firewall?

It is an intermediary, not automatically a complete firewall. Some products provide filtering or integrate a web application firewall. Network rules, authentication and application security remain separate parts of the design.

Key takeaway

A reverse proxy gives applications a controlled entry point. First establish how clients reach it, then configure how it selects and reaches each backend. Check both encryption legs, trust forwarded headers deliberately and test the real workload. For home hosting, public reachability and sustained upload capacity matter just as much as a working hostname.

To explore the related technical concepts used in this Reverse Proxy guide, visit our broadband terminology guide.