Capability

Your reverse proxy, explained and fixed

Test configs before they go live, read the right log, and reload safely, on nginx, IIS or Tomcat.

nginx nginx on Windows Reverse proxy Server blocks Upstreams IIS sites and app pools Tomcat systemd Access and error logs

In your words

Ask it like this

No syntax to learn. These are real requests, phrased the way people actually phrase them.

›the site is throwing 502, it was fine yesterday ›which config file is actually serving this domain ›why is nginx showing the default page ›add a site for staging.example.com pointing at port 4000 ›show me the error log for this site, last 100 lines ›test the config and reload it if it passes ›is this vhost proxying to the right port ›the upload keeps failing at around 2 MB

Capability

What it does here

Everything below is what the agent does today, not a roadmap.

Validate a config with nginx -t before anything is reloaded
Reload, restart, start and stop through root-owned wrapper scripts, never a raw shell
Find and tail the access/error log that actually matters for the request you are debugging
Work out which config file is actually serving a domain, across sites-available, sites-enabled and conf.d
Windows shops included: IIS sites, app pools and Tomcat get the same treatment

What it looks like

One question, one answer, one fix

The checks on the left of each reply are the reads it did before committing to an answer. That is the difference between a diagnosis and a guess.

Every exchange ends in a verified outcome. It goes back and confirms the result rather than assuming the fix worked.

brynko devOps Agent

the site is throwing 502, it was fine yesterday

read the error log checked the vhost listed ports

nginx is fine and so is your app. The error log repeats connect() failed (111: Connection refused) for upstream 127.0.0.1:8019, but nothing is listening there. Your container is bound to 9014. The port changed at the last deploy and the vhost still points at the old one.

point nginx at the right one

one line in the vhost nginx -t passed reloaded

Done. I changed the upstream port in your site config, tested it before applying, and reloaded. The site is returning 200 again.

Fixed · 200 OK

Common cases

The ones that cost you an afternoon

Each of these is a specific failure with a specific set of checks behind it, not a general promise to help.

Tomcat returns 404 after a WAR deploy

The WAR deploys with no error and Manager lists the application as running, but the URL you expect returns 404.

What it does. It checks which context path Tomcat actually assigned - the WAR file name, and any context file under conf/Catalina/localhost that overrides it - and tails the log covering that request, so you find out whether the app is live at a different path or not serving the request at all.

502 Bad Gateway

nginx is running, the site is down, and the error page tells you nothing about which of the two sides is at fault.

What it does. It reads the error log and the vhost, then checks what is actually listening on the upstream port. Usually the app moved and the proxy did not, and it can tell you which one changed.

504 Gateway Timeout

The page hangs and then dies. The app looks fine when you check it directly, which makes it look like nginx is the problem.

What it does. It compares how long the upstream really takes against the proxy read timeout, so you find out whether to raise the timeout or fix the slow request, rather than guessing.

Config changes do nothing

You edited the file, reloaded, and the site behaves exactly as before. Everything looks correct in the file you opened.

What it does. It works out which file is genuinely serving that domain across sites-available, sites-enabled and conf.d, and finds the duplicate server block or missing symlink that is winning instead.

nginx shows the default page

A new domain lands on the welcome page instead of your app, and the config looks right.

What it does. It checks the server_name matching, whether the site is enabled, and whether the default server is catching the request first, which is what usually happens.

nginx will not start after an edit

A reload or restart fails and the site is now down, which is the worst possible moment to be reading syntax errors.

What it does. Every config change is validated with nginx -t before anything is applied, so a broken config is caught while the old one is still serving traffic.

413 Request Entity Too Large

Uploads fail beyond a certain size and the limit is not where you expect it to be.

What it does. It finds which layer is imposing the cap, since client_max_body_size can be set in the http, server or location block, and shows you the one that is actually applying.

Start to finish

What happens between the question and the fix

You describe the symptom
A status code, a domain, or just "the site is down". You do not need to know whether the answer is in the config, the log or the upstream.
It reads the real setup
The vhost that genuinely serves that domain, the error log, the listening ports and the service state. Reads need no approval.
It names one cause
With the log line or config directive it is based on, so you can confirm it in seconds instead of taking its word.
You approve the change
A red and green diff of the config, showing exactly which lines change. Nothing is written until you say so.
It validates, then reloads
nginx -t runs before anything is applied, so a syntax error never reaches a live reload. Then it checks the site actually responds.

The part that matters

Reading is free. Changing asks first.

Reads run instantly and need no permission, because reading cannot break anything. Anything that changes a system, whether that is a restart, an edit, an install or a delete, stops and tells you what it is about to change, on which server, and why. You see it written out, as the command it will run or a red and green diff of the file, so you are approving the actual thing rather than a description of it. Changes are backed up first, so undoing one is a click.

Read the security model

Questions

Nginx, specifically

Will it break my site while editing the config?

Every config change is validated with nginx -t before it is applied, so a syntax error is caught while the previous config is still serving traffic. You also see a red and green diff of the exact lines before anything is written, and the original file is snapshotted so reverting is one click.

Does it need root access on the server?

It does not need a root shell. Service actions like reload and restart go through root-owned wrapper scripts with a fixed set of allowed operations, rather than handing the agent a general privileged shell. Elevated access stays off until you turn it on per server.

Can it create a new site or vhost from scratch?

Yes. It can write a new server block for a domain and upstream you describe, test it, and enable it, with the whole file shown to you as a diff before it is written. Issuing the certificate for that domain is handled separately, on the SSL side.

How does it know which config file is serving a domain?

It reads the include chain the way nginx does rather than assuming a layout, so sites-available, sites-enabled, conf.d and a monolithic nginx.conf are all handled. That is often the whole answer when an edit appears to have no effect.

Does this work with IIS or Tomcat?

Yes. It detects the operating system when it connects, so a Windows web server is not a special case. IIS sites and application pools, and Tomcat on either platform, get the same read-freely and approve-before-changing treatment.

Can it read the access log to debug a specific request?

Yes. It finds the log that belongs to that site rather than the default one, which matters when a server has a dozen vhosts, and can filter to the requests you care about.

Also covered

The rest of the stack

Ship it, and know what shipped

Run your existing deploy scripts, watch the output live, and get a straight answer about whether it worked.

Ask your database what is wrong

Read-only checks and queries over your existing SSH connection, with credentials encrypted at rest.

Wildcard HTTPS, sorted in one step

Issue trusted, auto-renewing certificates, wildcards included, and get the paths handed straight back.

Your AWS account, in plain English

Read EC2, S3, Elastic IPs and EBS, spot what is quietly costing you money, and make changes only after you approve them.

Ask Jenkins what went wrong

Read jobs, builds, the queue and console logs, find out why a build failed, and trigger or stop builds with your approval.

It runs on your machine too

Build, run and fix projects on your own computer, including installing the runtime the project needs.

Try it on something that already annoys you

Point it at one server. You will know within an hour whether it earns its place.

Create an account See pricing