Using a Public Reverse Proxy in Front of a NAT VPS

A public reverse proxy can accept ordinary HTTPS traffic and forward it to an assigned NAT VPS endpoint. It requires a separate reachable ingress host or service, a working origin mapping and a deliberate TLS and firewall configuration.

The request path

The browser resolves app.example.com to the ingress address and connects on 443. The ingress terminates TLS or passes encrypted traffic according to its configuration, then contacts the origin's assigned public port. The NAT host forwards that connection into the VPS.

The ingress server needs its own public reachability. Installing a reverse proxy only inside the NAT guest does not create ownership of the shared address's public port 443.

Protect the origin

Prefer an authenticated encrypted origin path or a private tunnel when crossing untrusted networks. If using HTTPS to the origin, verify its certificate and hostname rather than disabling verification permanently. Limit the origin mapping to trusted proxy sources where supported.

Forward only the headers the application needs. Configure its trusted proxy list so arbitrary visitors cannot spoof client IPs or protocol information through request headers. Keep the administrative interface separate from the public application.

Know the trade-offs

The extra proxy adds cost, another failure point and an additional network path. Connection timeouts, upload limits and WebSocket support must match your application. Measure end-to-end behavior instead of evaluating only the origin VPS.

This is a general deployment pattern, not an included Autdo managed ingress feature. Read website requirements, DNS limitations and HTTPS certificates.

Reference: Nginx reverse proxy documentation.