Self-Host an API Proxy on a VPS (2026, Nginx & Caddy)

A self-hosted API proxy is a relay on your own server: clients call your domain, the server forwards the request to the upstream API, and the response travels back. The upstream URL never appears in client code. You gain one stable entry point, your own domain and TLS certificate, and a single choke point for adding auth, rate limiting, or caching — all under your control.

Compliance note: only proxy services you are authorized to use. Read the upstream API’s terms of service before you begin, confirm your use case is permitted, and follow the laws that apply in your jurisdiction. This guide is for legitimate engineering use — building internal tooling, consolidating API access, reducing vendor lock-in — not for circumventing access controls.

Why self-host an API proxy?

Running the proxy yourself solves several real problems at once.

One stable entry point. Upstream providers occasionally rename or version their base URLs. Behind your own domain, client code never changes when the upstream does.

Your own domain and HTTPS. You control the TLS certificate and can enforce HTTPS end-to-end. The upstream URL stays private; clients only ever see your domain.

Central auth, rate limiting, and caching. Instead of duplicating token validation or retry logic in every client, add it once at the proxy. Rate limiting at the edge protects both your quota and the upstream. Caching cacheable endpoints reduces latency and saves API calls.

Hide the upstream. If the upstream URL leaks, attackers can call it directly and bypass your controls. A proxy puts that layer between them.

Prerequisites

• A small VPS — 1 vCPU and 1 GB RAM is sufficient for most workloads. See Best VPS for Self-Hosting for provider comparisons.
• A domain resolving to the VPS — follow how to point a domain to a VPS if you have not done this.
• Nginx or Caddy installed on the server. Most Linux distributions ship Nginx in their package manager; Caddy has a single binary install.

Option A — Nginx reverse proxy

The config below proxies all traffic arriving at api.example.com to an upstream at upstream.example.com. Replace both with your real domains.

server {
    listen 80;
    server_name api.example.com;

    location / {
        proxy_pass         https://upstream.example.com;
        proxy_set_header   Host              upstream.example.com;
        proxy_set_header   X-Real-IP         $remote_addr;
        proxy_set_header   X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto $scheme;
        proxy_ssl_server_name on;

        proxy_connect_timeout 10s;
        proxy_read_timeout    30s;
        proxy_send_timeout    10s;
    }
}

After saving, run a config test and reload:

nginx -t && systemctl reload nginx

proxy_ssl_server_name on tells Nginx to send the correct SNI header when opening a TLS connection to the upstream — without it, many upstreams reject the connection.

Option B — Caddy

Caddy handles TLS certificate issuance and renewal automatically. The equivalent config is a single block in your Caddyfile:

api.example.com {
    reverse_proxy https://upstream.example.com {
        header_up Host upstream.example.com
    }
}

Start or restart the service:

systemctl restart caddy

Caddy contacts Let’s Encrypt, obtains a certificate for api.example.com, and begins serving HTTPS with no further steps. This is the fastest path to a working proxy if you do not need Nginx-specific features.

Adding HTTPS (Nginx route)

If you chose Nginx and prefer a graphical interface for certificate management, Nginx Proxy Manager provides a web UI that issues and renews Let’s Encrypt certificates for you — no manual Certbot commands. Follow the Nginx Proxy Manager setup guide to get it running, then add a proxy host pointing to your upstream.

For a purely command-line setup, Certbot with the --nginx plugin works just as well and integrates directly with your existing server block.

Hardening the proxy

Once the basic proxy is working, a few additions make it production-ready.

Rate limiting. Nginx’s limit_req_zone directive lets you define a shared memory zone keyed on client IP, then apply limit_req in the location block. Start permissive, watch your logs, and tighten the burst and rate values as you learn real traffic patterns. Do not pick numbers from a blog post — base them on your own usage.

Caching cacheable endpoints. Add a proxy_cache_path and enable proxy_cache for endpoints that return stable data. Caching dramatically reduces upstream calls and latency for read-heavy workloads. Skip caching for anything that modifies state or returns user-specific data.

Timeouts. The example config already includes proxy_connect_timeout, proxy_read_timeout, and proxy_send_timeout. Tune these to values slightly above the upstream’s documented response times so that legitimate slow requests succeed but hung connections are cleaned up promptly.

Strip internal headers. Use proxy_set_header Authorization "" or similar to prevent client headers from leaking to the upstream when you handle auth centrally at the proxy.

Troubleshooting

502 Bad Gateway — upstream unreachable or wrong SNI. The most common cause is a missing or incorrect proxy_ssl_server_name on when the upstream requires SNI. Add it if it is absent, or verify the upstream hostname resolves from the server with dig upstream.example.com.

SSL handshake failure to upstream. If Nginx cannot complete TLS with the upstream, confirm that proxy_ssl_name matches the certificate the upstream presents, and that the Host header you are forwarding matches as well. Mismatches cause handshake failures that look like generic 502 errors in the error log.

CORS errors in browser clients. The proxy does not add CORS headers by default. Add them in the location block with add_header Access-Control-Allow-Origin "*" and an add_header Access-Control-Allow-Headers line covering the headers your clients send. Preflight OPTIONS requests may need a dedicated return block.

Rate limiting too aggressive. If legitimate clients hit 429 responses during normal use, increase the burst parameter on limit_req — burst allows short spikes above the steady-state rate without immediately returning an error. Adjust gradually and watch error logs rather than guessing.

Which VPS to run it on

Network route quality matters more than raw specs for a proxy. If you are serving clients in mainland China or other regions with routing constraints, the VPS location and peering make a bigger difference than CPU. See Best VPS for China access for options optimized for that use case.

For general use, value and reliability are the main criteria. Hetzner offers the best price-to-performance ratio in Europe. Vultr has data centers spread across more regions, which is useful if you need low latency to a specific upstream location. Either works well for an API proxy.

Start with the Best VPS for Self-Hosting guide to compare providers and pick the right fit for your workload.