When a Service Won't Open, Don't Reinstall Yet

Technical environments change. Check versions, back up data and prepare a rollback for live services before following any procedure.

Record the exact symptom

“It won't open” is not yet a diagnosable description. Record the exact time, URL, client network, error text and last known working state. Different symptoms point to different layers:

Timeout: packets may not reach the target, or the return path may fail;
Connection refused: the address is reachable, but no service is listening or the port is actively rejected;
Certificate error: TCP and TLS have started, so inspect hostname, time and certificate chain;
502 / 504: the reverse proxy is reachable, but its upstream is failing;
404: a service returned a response; inspect virtual-host selection, routes or file paths.

Reinstalling or replacing the entire configuration destroys evidence and adds new variables.

Build two cross-checks

Try the same address from another device and another network. If one client fails, inspect that device's DNS, proxy, VPN, clock and local firewall. If every client fails, move toward the shared path or server.

Separate the domain from its addresses:

bash

dig A example.com +short
dig AAAA example.com +short
curl -4 -I https://example.com/
curl -6 -I https://example.com/

This quickly exposes stale DNS or an IPv6-only failure.

Work from outside to inside

Use the same order and retain each result:

Does the client resolve the expected address?
Is there a usable route to that address?
Is the destination TCP port reachable?
Is the server listening on the expected address and port?
Do host and upstream firewalls allow the traffic?
Does Nginx select the intended virtual host?
Is the upstream application running and reachable from the proxy host?
Does the application itself return the expected result?

On the server, inspect listeners and failed units:

bash

ss -lntp
systemctl --no-pager --failed

127.0.0.1:8080 and 0.0.0.0:8080 are different boundaries. Decide who should reach the process before changing its listener.

Read logs instead of guessing

Observe proxy and application logs while generating one fresh request with a known timestamp:

bash

sudo tail -f /var/log/nginx/access.log /var/log/nginx/error.log

No access-log entry means the request stopped before Nginx. A 502 entry moves the investigation toward the upstream address and the corresponding error. If Nginx is healthy but the application returns an error, continue into the application log.

Logs may contain public addresses, tokens, cookies or internal paths. Remove sensitive data before sharing them.

Change one variable

Make the smallest change that can test the hypothesis. Add only the required firewall rule; adjust only the suspect upstream address. Repeat the same validation after every change.

For Nginx, test before loading the new configuration:

bash

sudo nginx -t
sudo systemctl reload nginx

A valid syntax does not prove business behavior, but it prevents an obvious configuration failure from reaching the running service.

Finish and roll back

After recovery, repeat the test from the original client, an external network, IPv4 and IPv6, then watch the error log. Record the actual breakpoint, change, validation commands and the path back to the previous configuration.

A reliable troubleshooting path matters more than a larger collection of commands. Each observation should narrow the system instead of creating another unknown state.