ai newsDi., 20. Okt.
EilmeldungCloud, KI und Logistik: Amazon investiert 16 Milliarden Euro in Deutschland

Debugging an nginx 502 with an AI assistant next to your terminal

It's 3 AM, the pager goes off, and the site is answering every request with 502 Bad Gateway . You know the drill: SSH in, read the nginx error log, check the upstream, check the port, check memory. None of it is hard. Doing it half-asleep, without skipping a step, is. This post walks through that t

dev.toDienstag 15:07 · 20.10.4 Min. Lesezeit
Bild: dev.to

It's 3 AM, the pager goes off, and the site is answering every request with 502 Bad Gateway. You know the drill: SSH in, read the nginx error log, check the upstream, check the port, check memory. None of it is hard. Doing it half-asleep, without skipping a step, is.

This post walks through that triage the way I now do it in AI-SSH-Pro, an open-source SSH desktop client with an AI assistant docked next to the terminal. The idea is simple: the assistant reads output, proposes the next command and explains it. You decide what actually runs.

Screenshots use the English UI and the built-in demo host, so all data is simulated. Some sample AI replies in the demo are in Chinese.

nginx returns 502 when it is acting as a reverse proxy and gets no valid response from the upstream. In practice it is almost always one of these:

So the job is: find which line you have, then find why.

Connect to the web host, open the AI panel on the right and just type what you see, e.g. "nginx on web-01 returns 502, help me check".

The panel is bound to the terminal tab you're in, so the assistant knows which host it is talking about. A good first answer is a short explanation plus a couple of safe, read-only commands:

systemctl status nginx --no-pager sudo tail -n 50 /var/log/nginx/error.log Enter fullscreen mode Exit fullscreen mode Each suggested command shows up in a compact block with Copy / Run and a risk label (low / medium / high). Both of these are read-only, so they're labelled low.

If the log shows Connection refused, you already know the upstream isn't answering. That one line saves a lot of guessing.

Next questions write themselves: is the upstream running, is it listening where nginx expects, did the kernel kill it?

sudo ss -ltnp | grep -E ':(80|443|8080|9000)\b' systemctl status php-fpm --no-pager # or your app's unit sudo journalctl -k --since "1 hour ago" | grep -i -E "oom|killed process" Enter fullscreen mode Exit fullscreen mode Instead of reading raw ps output yourself, you can ask "list the top processes by memory". In the screenshot above the assistant proposes:

ps aux --sort = -%mem | head -n 11 Enter fullscreen mode Exit fullscreen mode It's labelled Risk: low, and because it's read-only it ran right away under the tab's policy ("Ran automatically under the AI execution policy"). The reply then summarizes the output: which process is using the most memory, how much, and whether it's something you should touch.

If you'd rather paste context than describe it, the input row has a button to attach terminal output to your question, so the assistant reads exactly what you're looking at.

Once the cause is clear, the fix usually mutates the host: restart the upstream, correct the socket path, bump a buffer, reload nginx.

sudo nginx -t && sudo systemctl reload nginx sudo systemctl restart php-fpm Enter fullscreen mode Exit fullscreen mode This is where the execution policy matters. AI-SSH-Pro has three levels:

You set it globally in Settings → AI, per host on the host's Safety card, or for the current tab only from the policy menu in the input row. The tab override is in memory only and resets on disconnect.

For an incident on a real web node, Confirm before run is the sweet spot: diagnostics flow without friction, and nothing restarts until you click.

Tired people make mistakes, so a few safety nets are built in rather than left to discipline:

Every terminal tab has its own conversation, and history is grouped per host. Next time web-01 acts up, open the history and the previous investigation is right there: which commands ran, what they returned, what fixed it. + New chat archives the current conversation instead of deleting it.

AI-initiated commands and dangerous operations also land in the audit log, which you can filter by time and export when writing up the incident.

The assistant talks to any OpenAI-compatible provider (OpenAI, DeepSeek, Qwen, and others). API keys are stored with the OS secure store on your machine and are not uploaded to any product cloud.

More details are on the project site. AI-SSH-Pro is MIT-licensed; stars, feedback and issues are very welcome.

How do you triage 502s today? I'd love to hear which checks you run first.

Quelle: dev.to (dev.to). Original öffnen