Debug Nginx proxy_pass URI rewrites with this free visual tool. Easily determine the resulting request URI for location blocks with and without trailing slashes.
AI Generation Prompt
Application Overview
The Nginx proxy_pass URI Rewriting Visualizer is a client-side tool designed to help developers and system administrators predict exactly how Nginx will manipulate URIs during reverse proxy requests. This tool eliminates the guesswork of 'trailing slash behavior' in Nginx configuration, preventing costly 404 errors and broken backend routing.
Technical Specification
- Architecture: Single-file HTML/CSS/JS. No backend, no cookies, no localStorage. All logic is handled in the browser memory.
- Constraint Compliance: Strictly sandboxed, no external analytics trackers, no dark mode, and mobile-responsive layout.
Core Features
- Dynamic Visualization: Interactive form fields that let users input:
Location Block Path(e.g., /api/)Proxy_pass Destination(e.g., http://backend/v1/)Incoming Request URI(e.g., /api/users/profile)
- Result Engine: Real-time JavaScript engine that computes the exact resulting URI using standard Nginx logic rules.
- Explanation Generator: A 'How it works' card that appears below the result, explaining why the URI was transformed (e.g., 'The proxy_pass directive contains a URI, so the location match is replaced').
- Copy-to-Clipboard: One-click functionality to copy the generated configuration block for immediate use.
UI Layout
- Header: Clean, modern title and brief description.
- Input Section: Three distinct, well-labeled fields for the Nginx configuration parameters.
- Visualization Area: A central dashboard card that displays the 'Request Transformation' visually, using clear arrows to show the 'Before' and 'After' states.
- Configuration Preview: A read-only code block displaying the resulting Nginx snippet.
Aesthetics & Design
- Color Palette: Professional light-mode aesthetic using deep slates for text (#1e293b), soft sky blues (#0ea5e9) for primary actions, and clean white backgrounds (#ffffff).
- Animations:
- Soft fade-in transitions when the result is calculated.
- Smooth box-shadow expansions on focus states for inputs.
- Subtle border-color transitions during hover states.
- Typography: Inter or System Sans-Serif font stack for maximum readability and a clean 'SaaS' feel.
Developer Directives
- Logic: Implement the core Nginx path-replacement logic exactly as specified in the Nginx documentation.
- No External Dependencies: Only use lightweight CDNs for styling (e.g., Tailwind CSS via CDN) and icon libraries (e.g., Phosphor Icons or FontAwesome via CDN).
- Performance: Ensure zero-latency responsiveness; the calculation must trigger on every input keystroke using an event listener debounce pattern.
- Security: Ensure all user input is sanitized/escaped before rendering to the DOM to prevent XSS. Treat all inputs as plain text.
Spread the word
Files being used
Frequently Asked Questions
Everything you need to know about using this application.
How does the Nginx proxy_pass trailing slash affect URI rewriting?
When you include a URI (like /api/) in your proxy_pass directive, Nginx replaces the location block match with that URI. If the location block is matched, the part of the URI matching the location block is replaced by the URI specified in the proxy_pass directive. Conversely, if you omit the URI in the proxy_pass directive (e.g., just proxy_pass http://backend;), Nginx passes the full original request URI to the upstream server. Understanding this subtle difference is critical for ensuring your reverse proxy routes traffic to the correct path on your application server.
What is the difference between proxy_pass with and without a URI?
The primary difference lies in path truncation. If you define 'proxy_pass http://backend/subdir/', Nginx will strip the location path from the incoming request and prepend '/subdir/' instead. This is often used to map external URL structures to different internal directory structures on your backend. If you use 'proxy_pass http://backend;', no path modification occurs. The server simply forwards the exact request path it received. This behavior is standard for many modern applications that expect to handle the full path internally, and using the wrong syntax often results in '404 Not Found' errors on your backend.
Can I use regex in location blocks with this tool?
While this tool specifically visualizes standard prefix location blocks, Nginx handles regex locations differently. In regex locations, proxy_pass must be defined without a URI component because the location block itself performs the pattern matching, and the original URI must be passed intact. If you attempt to use a URI in a proxy_pass directive within a regex location block, Nginx will throw an error upon reloading the configuration. This tool focuses on the most common prefix-based proxy configurations which represent the vast majority of production reverse proxy use cases.
Why does my proxy_pass result in a 404 error?
A 404 error often occurs because the resulting URI sent to the backend does not match any route handled by your application code. For example, if your proxy_pass rewrites '/app/login' to '/login', but your backend app expects '/app/login', the request will fail. Use this tool to simulate the rewrite process before applying changes to your production nginx.conf file. By verifying exactly what string is being passed to the upstream server, you can pinpoint whether your rewrite logic is misaligned with your backend application's routing structure.
