Separate HTTP publication from application execution and persistent data. A reverse proxy can organise routing and limits, but origin access, application authorisation, upstream capacity and recovery each require their own controls.
A web request crosses several responsibilities
A web server receives HTTP requests and can serve static files. An application process executes the project's dynamic behaviour, such as checking an account or querying a database. A reverse proxy receives requests on behalf of that process and forwards them to an upstream. One program may fulfil several roles, but separating the responsibilities makes configuration and recovery easier to reason about.
Trace one request from hostname resolution to the response. Record where TLS ends, which process chooses the route and which component can read application data. Do the same for an administrative request. This exercise often exposes a listener or hostname that was created for testing and accidentally remained reachable. The diagram should describe the deployed path rather than the architecture you hoped to build.
Use the edge to organise HTTP behaviour
NGINX documents both serving static content and forwarding requests to an upstream. Its worker architecture and HTTP modules provide configuration mechanisms, but a particular configuration still determines the behaviour. Define hostnames, upstreams and filesystem roots deliberately. Restrict the files that can be served so configuration, credentials and repository metadata never become downloadable because they happen to sit near the application.
Set appropriate limits for request bodies, timeouts and connections according to the application. Treat caches as a data decision: content tied to a user or permission cannot safely inherit a shared caching rule without review. Test authentication and cache behaviour together. Keep a reproducible configuration and validate changes before reloading the service, with a known route back to the previous working version.
| Layer | Useful responsibility | Check before launch |
|---|---|---|
| Public web edge | TLS, hostname routing and HTTP limits | Certificates, roots and intended hostnames |
| Application process | Business logic and authorisation | Authentication, input checks and dependency failure |
| Internal data service | Persistent application state | Restricted access and tested restoration |
| Upstream provider network | The contracted network service | Protection scope and escalation path |
A reverse proxy does not remove the origin's exposure
If the origin remains publicly accessible, a client may reach it without using the intended proxy route. Restrict origin access through the network design and application configuration when the deployment requires that boundary. On one machine, a backend can often listen on loopback or a local socket. Across machines, use explicit restricted routes and suitable protection for the upstream connection.
Forwarded headers need a trust rule too. Accept information about the original client only from trusted intermediaries, and prevent arbitrary callers from supplying values that the application treats as authoritative. Decide what appears in access logs and error reports. A proxy can change the information available at each layer; it does not erase account identifiers or make the application anonymous to its own operator.
Apply access decisions inside the application
NIST's Zero Trust architecture focuses on access decisions for resources rather than implicit trust based only on network location. Apply that principle concretely: authenticate the caller, authorise the requested operation and give service accounts only their required scope. A request arriving from an internal subnet should not automatically become an administrator request.
Separate public and administrative functions where practical. Recheck permission when a user accesses a record rather than relying only on the initial login. Keep credentials for the proxy, application and database distinct. Introduce changes in stages that can be tested, beginning with a narrow sensitive path. Calling a deployment Zero Trust is less useful than demonstrating that a forbidden action is actually denied at the component responsible for it.
Plan denial of service at more than one layer
A saturated network link and an expensive application request fail at different places. Rate limiting at the web edge may help constrain request patterns, while application limits can bound work such as searches, uploads or exports. NGINX's request-limit module supplies one mechanism; the key and thresholds must fit real users and be tested to avoid rejecting legitimate traffic.
OWASP's denial-of-service guidance also addresses resource exhaustion in application behaviour. Put time and size limits around expensive work, use bounded queues and monitor failure signals. Local controls cannot create capacity in an upstream link that is already saturated. Confirm the specific network protection included in the chosen offer and prepare an escalation path. Never assume a catalogue's Layer 3–4 protection also proves protection for every HTTP workload.
Make recovery part of the publication
Check the site from an external client using its intended hostname. Verify HTTPS, redirects, static resources, logins and a representative application transaction. Confirm that administrative listeners and private files remain inaccessible. Simulate a stopped upstream and check that the edge returns a controlled failure rather than exposing internal details or waiting without a limit.
For Canvas, read the controls available within the hosting account. For a VPS, maintain the web edge and application as part of your own operating plan. A large network port is a capacity specification, not proof that the application can sustain that throughput. Keep monitoring, restoration and provider contacts in the runbook. Publish only after the actual request path and a practical recovery path have been verified.
Your practical checklist.
- Trace a public and an administrative request.
- Define served roots and upstream listeners.
- Trust forwarded headers only from approved intermediaries.
- Test authorisation and cache boundaries.
- Prepare limits and escalation for network and application failures.
The details that matter.
Can a web server also act as a reverse proxy?+
Yes. NGINX is one documented example. Its roles depend on the configuration, and the application still needs its own authorisation and maintenance.
Does a reverse proxy automatically hide the origin?+
No. The origin may remain reachable unless routing, firewall and listener settings enforce the intended boundary.
Will request limiting stop every DDoS attack?+
No. It addresses selected HTTP request patterns. Network saturation and other resource failures require appropriate upstream and application controls.
Go to the source.
These references support the technical concepts in this guide. Follow the current documentation before changing a production system.
- NGINX: Beginner's guide nginx.org
- NGINX: HTTP request limiting nginx.org
- NIST SP 800-207: Zero Trust Architecture nvlpubs.nist.gov
- OWASP: Denial of Service Prevention cheatsheetseries.owasp.org
Editorial guidance by SwissOctet. Examples are illustrative. Service specifications, available options and contractual conditions must be verified separately.