One public entrance can serve several applications.
A reverse proxy sits in front of application servers. It receives client requests and forwards them to the relevant backend, then returns responses. It can provide a common place for routing and other connection handling.
A studio might serve www.example.com, app.example.com and api.example.com through one gateway. Their DNS records can lead to that gateway while the proxy configuration decides which service receives each request. Sharing an entrance does not mean all three names run the same application.
Reference: NGINX: reverse proxy conceptsChoose the service, then choose an instance.
Hostname or path rules can select a destination service. When that service has several suitable instances, a load-balancing policy can distribute work among them. These are two decisions: which application should answer, and which copy should handle this request?
The interactive route map makes those decisions visible. Select the website, API, or an example in which one API instance is unavailable. The final state assumes the gateway has detected the failure and excluded that instance. Actual detection timing and behavior depend on the deployed system.
Reference: NGINX: HTTP load balancingDNS, proxies and applications work at different layers.
DNS resolves a hostname to information used to locate a destination. A reverse proxy processes the connection at that destination and can route HTTP requests onward. The application implements the actual page or API behavior. Changing one layer does not automatically configure the others.
If a user reaches the wrong service, inspect the requested hostname, DNS answer, gateway rule and backend response in order. This is usually clearer than making several changes at once. A readable routing inventory helps especially when different projects share the same fleet.
| Decision | Example | Handled by |
|---|---|---|
| Find the entrance | api.example.com → gateway address | DNS |
| Choose the service | API hostname → API pool | Routing rule |
| Choose a copy | API pool → instance 02 | Load-balancing policy |
| Do the work | Return the requested record | Application |
Two application copies need to agree on the important things.
If a user signs in through one application copy and the next request goes to another, session handling needs to work across that arrangement. Files written only to one instance may be absent from another. Adding replicas can reveal assumptions that were invisible on a single server.
For the studio’s dashboard, identify where sessions, uploads and background jobs live before adding instances. Some systems use shared services for state; others use an explicit affinity strategy. The right choice depends on the application, and balancing alone does not make state portable.
The gateway is part of the application’s reliability.
Watch the gateway as well as the backends. A healthy API cannot serve public traffic through an unavailable entrance. Review certificates, connection limits, timeouts and error responses as part of the route, rather than treating the proxy as invisible plumbing.
For a planned change, identify the old destination, new destination and how you will verify the switch. Make health checks reflect useful readiness, and give failed requests a diagnosable path. More replicas can improve capacity or resilience, but neither outcome is automatic without the surrounding design.
Common questions.
Is a reverse proxy the same as DNS?
No. DNS helps locate a destination; the proxy handles and forwards requests after clients reach it.
Do I need a separate server for each subdomain?
No. Several hostnames can route through one gateway to services on the same or different hosts.
Does load balancing automatically scale my servers?
No. Distributing requests and adding computing capacity are separate capabilities.
Connect the concept to your work.
DOCKOCK connects public routes with services and server or cluster destinations, so the path from hostname to workload stays visible.
Explore traffic routing in DOCKOCKKeep learning from the source.
Further reading from the teams and documentation behind these technologies.
NGINX: reverse proxy conceptsNGINX: HTTP load balancing