Record the exact hostname, expected service, error and time. Confirm whether the application runs on the host, in a container or inside a VPN, because each can use different routing and resolver settings. Use only authorized diagnostic targets.

1. Inspect the server address and route with ip address and ip route. Confirm the intended network is present before testing name resolution.
2. Test an appropriate known endpoint by IP using its expected protocol. A failed ping alone is inconclusive because ICMP may be filtered.
3. Query the hostname through the system resolver using getent ahosts HOSTNAME. Where systemd-resolved is used, inspect resolvectl status and its query result.
4. Compare with a direct DNS query to the intended resolver if needed. Distinguish timeout, NXDOMAIN, SERVFAIL and a valid but unexpected answer.
5. Check whether /etc/resolv.conf is managed by NetworkManager, systemd-resolved or cloud provisioning. Correct the owning configuration rather than making a temporary edit that will be overwritten.
6. After a targeted change, test the original application using the hostname and expected TLS identity.

Run these from the Linux host that cannot reach the service. Replace example.com and 192.0.2.10 with the service name and its verified destination address. The IP is a documentation placeholder, not a Nabtech server address.

getent ahosts example.com
ip route get 192.0.2.10
curl --connect-timeout 10 --max-time 20 --head https://example.com/

Read the result: getent follows the system's configured name-service order, which can include local hosts entries. The route command shows how the kernel would send traffic to the destination. curl then tests the actual HTTPS path and certificate handling. These checks identify different layers and should not be treated as interchangeable.

If the name fails but the route is present, inspect the configured resolver. If DNS works but curl reports a connection or TLS error, investigate that layer. A route entry does not prove a remote port is reachable.

A direct DNS query may bypass the application's resolver path, hosts file, cache or container environment. Test through the system and runtime the application actually uses.

Confirm the system resolver returns the intended addresses and the actual service responds. Check both IPv4 and IPv6 when the hostname publishes both. Verify that private or split-DNS names still resolve correctly after any resolver change.

If direct-IP tests succeed but names fail, focus on resolver reachability and configuration. If resolution succeeds but connection fails, inspect service listeners, routing and firewalls. Avoid replacing corporate/private resolvers with public ones without understanding split DNS and access requirements.

• Changing Ubuntu server networking with Netplan safely
• Changing an AlmaLinux or Rocky Linux address with NetworkManager
• Finding which process listens on a Linux network port
• Diagnosing Linux TLS errors caused by trust or clock problems

• Debian manual: Getent.1.en
• Debian manual: Resolvectl.1.en
• Debian manual: Ip.8.en

• curl command reference