A reverse proxy provides the public connection boundary for a self-hosted Next.js process. It should forward the application correctly while enforcing appropriate request and connection limits.
IN THIS ARTICLE
01 What you need before you begin
Confirm the supported proxy configuration, internal listener and TLS endpoint. Identify streamed responses, server functions and upload workflows that must pass through it.
02 Protect a Next.js deployment with a reverse proxy
Route the public hostname to the correct internal application endpoint and keep the upstream listener restricted to the intended network path.
Configure HTTPS and the forwarded host and scheme behavior expected by the app. Test redirects and any permitted server-function origins.
Set deliberate request-size, timeout and rate controls that fit real application workflows. Avoid removing all limits because one request failed.
Respect Next.js cache directives and response variants. Keep authenticated or personalised content out of a generic public page cache.
Configure streaming behavior for routes that require it and verify the proxy does not buffer away the application’s intended progressive response.
03 Confirm the expected result
Test normal navigation, an authenticated request, an upload and a streamed page. Check both success and controlled error responses through the public hostname.
04 Troubleshoot unexpected results
If a feature works on the internal listener but fails publicly, compare the proxy’s timeout, path, headers and caching behavior. A proxy response should not be mistaken for a framework error.
05 A common question
Can I put a simple cache-everything rule in front of the app?
Only cache content with an appropriate design and cache key. Blanket caching can expose user-specific content or mix navigation response variants.
06 Example: investigate a gateway error after starting Next.js
Begin with the application log and the configured hosting route. Confirm that the production process is running under the expected account and listening on the port assigned by your deployment environment.
A proxy configuration must reach that listener while presenting the public hostname and HTTPS correctly to the application. Do not expose an internal application port to the whole internet merely to avoid diagnosing the supported proxy path.
What should I test through the public URL?
Open a normal page, a directly entered nested URL and a feature that uses an application endpoint. Check the response codes and any asset failures. A cached home page can hide a broken backend, so test an action that proves the active application is responding.
Record whether a CDN is also present and whether the same failure happens without a cached response. When contacting us, provide the deployment mode, startup command, assigned port and relevant errors. Remove credentials from commands and logs. Next.js static output and a continuously running Node.js application have different hosting requirements, so name the mode rather than describing both simply as a JavaScript site.