A Minimal Nginx Routing Setup on a Shared VPS

Topology

:443 ─ Nginx ─┬─→ / ────────→ /var/www/blog/ (static files)
              ├─→ /api/* ────→ 127.0.0.1:3001 (Node API)
              └─→ ws-service ─→ 127.0.0.1:10086 (WebSocket)

This historical setup used a single port 443 entry point. Nginx distributed requests by path between the static site and local services.

Minimal configuration

server {
  listen 443 ssl http2;
  server_name fankex.com;

  ssl_certificate     /etc/letsencrypt/live/fankex.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/fankex.com/privkey.pem;

  root /var/www/blog;
  index index.html;

  location / {
    try_files $uri $uri/ =404;
  }

  location /api/ {
    proxy_pass http://127.0.0.1:3001/;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
  }

  location /socket {
    if ($http_upgrade != "websocket") { return 404; }
    proxy_pass http://127.0.0.1:10086;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
  }
}

Three common traps

1. A trailing slash on proxy_pass changes the forwarded path; decide explicitly whether to preserve the prefix.
2. A WebSocket proxy needs explicit upgrade headers.
3. Fonts, images, styles, and scripts with content hashes suit long immutable caching; HTML does not suit the same policy.

This is a durable record of the VPS configuration. Managed hosting is the approved target and migration remains in progress; until cutover is verified, this note does not characterize what currently serves production.