I have a folder of nginx.conf snippets I shouldn't admit to. proxy_pass from a Stack Overflow answer. A location block from a blog post written in 2019. Something about try_files I pasted at 1 a.m. because the SPA was returning 404s.
They worked. That's the annoying part. A week later I couldn't explain why they worked. And the next time the same shape of bug showed up, I opened that folder again instead of thinking.
If you've spent any time putting apps behind a reverse proxy, you know this loop. Nginx is simple enough that copy-paste gets you shipping. It's also precise enough that "simple" is a trap.
What actually sticks
Nginx stops feeling mystical once you can draw three boxes on a napkin:
- A server listens on a port and decides which hostnames it owns.
- A location matches a path and decides what happens next.
- Something upstream (your app, another service, a static file) receives the request.
Everything else (headers, SSL, buffering, WebSockets) hangs off that mental model. Without it, every tutorial is a bag of spells.
Here's a tiny config that teaches more than a 40-line paste:
server {
listen 80;
server_name api.example.com;
location / {
proxy_pass http://127.0.0.1:3000;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
Read it out loud once. Port 80. Hostname api.example.com. Every path goes to a process on 3000. Two headers so the app knows who the client was.
Change one line at a time. Point proxy_pass at a different port and watch the response change. Add a second location /health that returns 200 with return. Break server_name on purpose. The goal isn't elegance. It's friction that forces the boxes into your head.
The week-later problem
Most of us "learn" Nginx while fixing something. Prod is down, the certificate expired, the Docker network renamed itself. You find a matching snippet, ship it, close the tab.
That works for the incident. It fails for the next one. Your brain stored the outcome ("site came back") and forgot the structure ("this location never hit proxy_pass because the regex location above it won").
I've done this with proxy_redirect, with client_max_body_size, with the difference between proxy_pass http://backend; and proxy_pass http://backend/;. Same story every time: I understood it for an afternoon.
Spaced recall is the boring fix. Not a second marathon of docs. Short questions a few days later, while the context is still warm but not sitting in working memory.
Ask yourself, without looking:
- What does a trailing slash on
proxy_passchange? - When does Nginx pick a regex
locationover a prefix one? - Where does
$hostcome from if the client sent no Host header?
If you blank, reopen the note. If you nail it, ask again in a week. That's the whole habit. No fancy system required. A calendar reminder and a notebook beat another unread bookmark.
Save the tutorial. Don't trust the tab.
The other half of the mess is source material. Official docs, DigitalOcean how-tos, random GitHub gists, a 25-minute YouTube walkthrough of TLS termination. You open five of them during an outage. You close all five when it's fixed.
Two weeks later you need the same idea and start over.
What helps me is a short loop:
Capture while you're still in the problem. Share the doc, the video, the gist into one place before you close the browser. If you wait until "later," later never comes.
Get a short summary while it's fresh. TL;DR, key takeaways, the bits you'd actually rewrite from memory. Write one sentence of your own on top: "Trailing slash on proxy_pass strips the location prefix. Burned me on /api." Your note beats the original article when you're debugging at night.
Put it somewhere you'll see again. Folders or topics named like the concepts (reverse proxy, TLS, static SPA) beat a chronological dump of twenty "nginx" bookmarks.
Get nudged to recall. A push that asks "still remember this?" turns a saved page into something your brain has to retrieve. Weekly quizzes on what you saved that week work the same way. Retrieval is the point; rereading is optional.
I built Recl around that loop: save anything (docs, YouTube, articles, notes), get an AI summary with takeaways, drop it into library topics, then get recall nudges and a weekly quiz so the mental model comes back on a schedule. Soft plug, I know. Use a notebook if you prefer. The method matters more than the tool.
Chrome users: the extension's Ctrl/Cmd+Shift+S save is useful when you're mid-debug and don't want to leave the tab. Share-sheet save on mobile works the same for phone-reading docs on the train.
A weekend practice plan
If you want something concrete for the next two days:
Saturday morning: one reverse proxy. Run a local app on 3000. Put Nginx in front with the tiny config above. Hit it. Break proxy_set_header Host. Fix it. Save the doc you used and write three takeaways in your own words.
Saturday afternoon: one static site. Serve a built SPA with try_files $uri /index.html. Force a refresh on a deep route. Notice what 404s without that line. Save that note under a "static + SPA" topic.
Sunday: TLS once, slowly. Terminate HTTPS locally with a self-signed cert. Don't chase every flag. Get listen 443 ssl working and understand which file is the cert and which is the key. Save the walkthrough. Answer two recall questions before bed: where does the private key live, and what happens if server_name doesn't match the cert.
Next Wednesday: reopen nothing. Answer the three napkin questions from earlier from memory. Only then open your saves. That gap is where learning happens.
You don't need to memorize the entire Nginx docs. You need the three boxes to stay upright when the next incident arrives. Copy-paste gets you through Friday night. A saved summary you can actually recall gets you through the month after.
I'm Asutosh, building Recl — save what matters, recall it forever.


Top comments (0)