A computer can have an IP address and still fail to reach the internet. It also needs the right subnet prefix and a route toward other networks. To reach sites by name, it usually needs a working DNS server. Network configuration tools help you check each piece, find out what manages it, and change it without guessing.
The examples focus on Linux, with Windows and macOS equivalents where useful. Run these checks on a computer or lab machine you own or administer. Looking at settings is generally low risk; changing an address, route, or resolver can interrupt a connection, especially on a remote server.
Know which settings you are looking at
Start with four things: the network interface, its IP address and prefix, the default route, and the DNS configuration. An interface might be a wired adapter such as enp0s3, a wireless adapter, or a virtual interface. Its address identifies it on a network. A prefix such as /24 defines the local address range, but it does not tell the computer where to send traffic beyond that range.
The default route supplies a next hop, commonly a router. DNS servers answer name-lookup requests. If an application cannot reach a site by name, DNS may be the problem even when the interface and route work. Changing DNS, though, will not fix a missing default route.
Read the current state before changing it
Interfaces and addresses
On most modern Linux distributions, ip is the basic tool for viewing addresses and routes. ip -br address gives a compact list of interfaces and assigned addresses. For more detail, ip address show displays interface state, IPv4 and IPv6 addresses, and prefix lengths. UP can mean an interface is administratively enabled; check for an actual physical link or Wi-Fi connection before assuming it can carry traffic.
On Windows, ipconfig /all displays adapter addresses, gateways, DNS servers, and DHCP details. On macOS, ifconfig shows interface addresses, though the Network settings panel is often easier for finding the active service. Names and output vary by operating system. What matters is identifying the adapter carrying the connection you are troubleshooting.
Routes and name resolution
Use ip route show on Linux to see IPv4 routes. A line beginning with default via shows the usual next hop for destinations outside directly connected networks. Check IPv6 separately with ip -6 route show. Windows has route print; macOS has netstat -rn. Multiple default routes can be valid, but then you need to check which interface the system prefers.
DNS takes a little more care. Linux may use NetworkManager, systemd-resolved, or another service, so /etc/resolv.conf may be generated rather than a file you should edit. If the system uses systemd-resolved, resolvectl status shows DNS servers for each link. On Windows, ipconfig /all lists configured servers. On macOS, check the DNS tab for the selected service in Network settings.
Find the tool that owns the configuration
Reading the current state and changing persistent settings are different jobs. The Linux ip command can make immediate changes, but they often disappear after a reboot or when a network manager reapplies its configuration. Before editing files or changing settings, find out whether NetworkManager, systemd-networkd, a distribution-specific system, or a cloud platform manages the connection.
On a Linux desktop using NetworkManager, nmcli device status shows devices and their connection state; nmcli connection show lists saved profiles. The device is the interface, while the profile holds settings NetworkManager can apply to it. A laptop, for example, may have separate profiles for home Wi-Fi and a lab network.
Some servers use systemd-networkd, with network files maintained by an administrator or deployment system. Others use a layer that generates those files. Editing generated output may work briefly before it is overwritten. On Windows and macOS, graphical network settings are a sensible starting point for beginners. Command-line tools help with inspection, but not every value they display is meant to be edited there.
Choose DHCP or a static address deliberately
DHCP requests settings such as an IP address, prefix, gateway, and DNS servers from a network service. It is the normal choice for laptops and many lab guests. A changed DHCP address is not necessarily an error; the network may have issued a different lease. Check the DHCP server or lease information before replacing working automatic settings with a manual address.
A static address makes sense when a machine needs to stay reachable at a known address, provided the network administrator has allocated it. The address must fit the network prefix and must not conflict with another host or the DHCP allocation policy. The gateway normally needs to be reachable on a connected network. Record the old settings and arrange local or console access before changing a remote host: a mistyped gateway can end your SSH session.
For example, a lab interface assigned 192.0.2.10/24 could use 192.0.2.1 as its gateway only if that router exists on the lab segment. These documentation-only addresses show the relationship; they are not values to copy onto a real network. A plausible subnet calculation cannot tell you whether the gateway is present or forwards traffic.
Use the right tool for each check
| Tool or setting | What it helps establish | What it cannot establish alone |
|---|---|---|
| ip address or ipconfig /all | Assigned addresses and adapter details | Whether the gateway or internet works |
| ip route or route print | Where the system plans to send traffic | Whether the next hop responds |
| resolvectl status or DNS settings | Which resolvers are configured | Whether a specific name resolves correctly |
| ping | Whether a permitted target replies to ICMP echo | Whether every application protocol works |
| nslookup | A DNS lookup result from a resolver | Whether an application can connect to the result |
Each tool answers a different question. A failed ping does not prove a host is down; a firewall or network may block ICMP echo replies. A successful DNS lookup means a name returned a result, not that its web service is available. Test only targets you own or are authorized to check, and do not build a diagnosis around one command.
A safe workflow for a broken lab connection
Suppose a virtual machine can reach another machine on its lab subnet but cannot reach an approved service on a different subnet. Save the original output, then work outward:
- Identify the active interface. Check its address and prefix. If it lacks the expected address, inspect its connection profile or DHCP state before looking at DNS.
- Inspect the route table. Look for a route to the destination network or a default route. It may point to an interface or gateway that is no longer in use.
- Check the next hop. If the lab permits ICMP tests, try the configured gateway. No reply is a clue, not a verdict; check the gateway address and link state too.
- Check DNS if names are failing. Compare a lookup of the authorized service’s name with connectivity to its known address. A lookup failure suggests a resolver issue; an address-based connection failure calls for further route or service checks.
- Change one setting, then recheck. Make the correction through the service that manages the interface. Verify the live address, route, or DNS setting, then retest the original failure.
That order helps separate a configuration mistake from a service outage. If other lab machines reach the destination and yours has the wrong gateway, changing DNS is unlikely to help. If the route works but names fail, changing the gateway just adds another variable.
Make changes that survive—and can be undone
Temporary commands are useful for controlled experiments, but a persistent fix belongs in the connection profile or configuration source the system uses. Before saving a change, check whether the interface gets settings from DHCP and whether another tool manages it. Avoid running competing network managers on the same interface.
Verify both the live state and the saved configuration afterward. A profile can contain the correct gateway while the active connection still uses the old one. Reconnecting may be necessary, but it briefly interrupts traffic, so arrange console access or another recovery path for remote work. In a local lab, save the current ip -br address and ip route show output, restart the guest when safe, and compare the results after it reconnects.
