Nginx Config Visualizer

Demo: explain a reverse proxy before deployment

For an API gateway or edge proxy, reviewers need to know which path reaches which upstream. A diagram makes that relationship visible without forcing everyone to parse nginx syntax.

• Group locations by server_name when multiple domains share one file.
• Flag catch-all locations because they can hide more specific routes.
• Compare proxy_pass targets with service names used in Docker Compose or Kubernetes.

upstream api_backend {
  server api:8080;
}
server {
  server_name example.com;
  location /api/ { proxy_pass http://api_backend; }
  location /assets/ { root /var/www; }
}

This source should produce a server node, an upstream node, and separate route edges for /api/ and /assets/.

Debug pattern: review route precedence before deployment

Nginx incidents often come from location precedence, proxy headers, or a rewrite rule that works for one path and breaks another. A visual preview should make the route order easier to inspect before a config reaches production.

• Compare exact, prefix, and regex locations in the order Nginx will evaluate them.
• Check proxy_set_header values when upstream apps rely on host, scheme, or client IP.
• Review cache, gzip, and static asset blocks separately from API proxy blocks.

location = /health { return 200; }
location /api/ { proxy_pass http://api:8080; }
location ~* \.(js|css|png)$ { expires 30d; }