Is it DNS, the network, or your application?

When a server becomes unreachable, changing DNS, firewall rules and application settings together makes the result harder to understand. A better investigation keeps those layers separate and records what each test proves.

Start with the account and incident state

Check your service status and the public status page. Record when the failure began and whether it affects every user or just one network. Then open the management panel if it is available.

A suspended service, an application stuck in a restart loop and a regional connectivity problem need different responses. The same browser error can hide all three.

Test the name separately

Compare the hostname's DNS answer with the destination you intended. Confirm that you edited records at the authoritative DNS provider, not an account that used to host the zone.

Cached answers can persist for their TTL. An updated authoritative record does not force every resolver to forget an earlier answer immediately. Cloudflare's TTL documentation explains that distinction.

Also inspect IPv6 when an AAAA record exists. Some clients can prefer a different address family, making a partial DNS error look like an intermittent application failure.

Check the destination service

Once the address is correct, verify the intended protocol and port. A name resolving successfully does not mean a program is listening. Likewise, a server process running does not prove that its port is reachable from the outside.

Use read-only observations before changing rules. On an Ubuntu server, a check of the existing firewall configuration is safer than enabling a new policy without preserving SSH access. Follow the official Ubuntu firewall guide for the commands appropriate to your system.

Preserve useful evidence

Save the error text, last relevant console output and the timing of recent changes. If you need support, send the service ID and the tests already performed. Keep private addresses and credentials out of public screenshots.

Do not reinstall the application merely because the cause is unclear. A destructive change can remove logs and data while leaving the original DNS or network issue untouched.

Use the DNS verification checklist and incident report guide to turn an uncertain symptom into a useful report.