vendor hub
NGINX
Everything on ronutz.com for NGINX, in one place: every tool, grouped by family, followed by every article. Tools compute locally in your browser; articles are grounded in vendor documentation.
Tools (3)
More
NGINX cache decision explainer
Two different questions: will this response be stored, and will a later request be served from it. Paste the directives and the exchange to see both answers and why.
RangkaianNGINX location matcher
Paste your location blocks and a URI, and watch NGINX's five-step selection run: exact, longest prefix, the caret-tilde early exit, regexes in file order, then the fallback.
RangkaianNGINX proxy_pass rewriter
One trailing slash decides whether your backend sees /app/page or /page. Paste the directive and see both answers side by side.
Rangkaian
Articles (8)
More
Apache httpd: the server that ran the web, and the problem that produced NGINX
Apache began as patches to a server nobody was maintaining, and within a year it ran more of the web than anything else. The architecture that made it flexible is also the one that made it struggle under 2000s traffic, which is the problem NGINX was written to solve.
RangkaianReadKadens keluaran F5 yang lebih pantas: keluaran diperkukuh dan pemberitahuan keselamatan bulanan
Pada 6 Julai 2026, F5 beralih daripada kadens keselamatan suku tahunan kepada bulanan: keluaran perisian diperkukuh pada Rabu ketiga setiap bulan mulai 15 Julai, dan pemberitahuan keselamatan sebulan kemudian mulai 19 Ogos. Inilah dengan tepat apa yang berubah, mengapa F5 kata ia berubah, apa yang kekal sama, dan apa maknanya bagi cara anda menampal.
RangkaianReadLimiting requests, connections and bandwidth in NGINX: leaky buckets and the burst that surprises people
Three different limits, three different directives, and one shared mechanism worth understanding before you tune it. The request limiter is a leaky bucket, not a quota per second, and burst plus nodelay change its behaviour in ways the names do not suggest.
RangkaianReadNGINX caching: what gets stored, what gets served, and the gap where user data leaks
Whether a response is stored and whether a later request is served from it are different questions with different answers. NGINX protects you from caching a cookied response, and does not protect you from serving a cached response to a cookied request. That asymmetry is where one user receives another user's page.
RangkaianReadNGINX location matching: why the block you expected is not the one that ran
NGINX does not pick the first location that matches, and it does not pick the last. It follows a fixed five-step order in which the file's own order matters for exactly one step, which is why reading a config top to bottom will mislead you about which block wins.
RangkaianReadReloading NGINX without dropping traffic, and the first four things to check when it breaks
A reload is not a restart: the master validates the new configuration, starts new workers, and lets the old ones finish what they were doing. Knowing that, and knowing which log answers which question, resolves most NGINX problems before they become interesting.
RangkaianReadThe NGINX configuration tree: what includes, in what order, and who owns the worker
One file, a directory of fragments, and an include order that decides which directive wins. Plus the two ownership questions that explain most permission failures: which user the master runs as, which user the workers run as, and why those are deliberately different.
RangkaianReadThe NGINX proxy_pass trailing slash: one character that decides what your backend receives
proxy_pass with a URI part replaces the matched location prefix. Without one, the original request URI passes straight through. That is the entire rule, it is a binary switch rather than a shade of difference, and a single slash is enough to flip it.
RangkaianRead