A laptop shows that it is connected to Wi-Fi. The signal looks fine, and the user can open some websites, but an important business application refuses to load.
The first instinct might be to restart the router, reset the network adapter, or change a few settings until something works. Sometimes one of those actions helps, but none explains what actually failed.
A better approach is to narrow down the problem before making changes.
This walkthrough uses a fictional office-network scenario to explain how a technician can investigate connectivity problems systematically. It also illustrates practical concepts relevant to the CompTIA Network+ N10-009 certification.
Start by Defining the Actual Problem
Suppose an employee reports that the company's internal portal stopped loading after they moved to another desk.
Before changing anything, establish the scope of the issue.
Ask a few specific questions:
- Can the employee access other websites and internal applications?
- Is the problem limited to this laptop, or are nearby employees affected?
- Does the problem occur on Wi-Fi only, or does it also occur over a wired connection?
- When did the problem begin?
- Was there a recent change to the device, network, VPN, or application?
These questions help separate a device-specific fault from a wider network issue.
If every employee on the same wireless network experiences the problem, investigating one laptop's browser settings may not be the best starting point. If only one device is affected, checking the shared network infrastructure first may also waste time.
The goal is to identify a useful boundary for the investigation.
1. Check the Physical and Wireless Connection
Begin with the nearest connection point.
For a wireless device, confirm that it is connected to the intended SSID, has a usable signal, and has completed any required authentication or captive-portal process.
For a wired device, check the cable, physical link indicators, switch-port status, and whether the connection is operating at the expected speed.
A connected Wi-Fi icon does not guarantee that every network service is working. It usually indicates that the device has established a wireless connection, not that DNS, routing, or the target application is functioning correctly.
In an office, a user might also be connected to a guest network rather than the employee network. Both networks may provide wireless access, but their VLANs and access policies may differ.
What this tells you: Whether the failure is likely to involve the initial connection, authentication, signal quality, or the network path beyond the access point.
2. Verify the Device’s IP Configuration
Once the connection appears healthy, examine the device's network configuration.
On Windows, run:
ipconfig /all
Review the assigned IPv4 address, subnet mask, default gateway, DHCP information, and DNS servers. Compare them with the expected configuration for that network.
A device that receives an IPv4 address in the 169.254.0.0/16 range may have assigned itself an Automatic Private IP Addressing (APIPA) address because it could not obtain a suitable DHCP lease.
That observation is useful, but it is not the final diagnosis. You still need to establish why address assignment failed.
Possible causes include:
- A DHCP service that is unavailable.
- An exhausted DHCP address pool.
- A problem with the wireless or switch VLAN.
- A DHCP relay or network configuration issue.
- A problem affecting only the client adapter or its configuration.
The next check depends on the scope of the problem. If several devices on the same segment cannot obtain valid addresses, investigate the shared DHCP and network path. If other devices work normally, inspect the affected client's connection and settings more closely.
Avoid manually assigning an arbitrary IP address simply to make the warning disappear. An incorrect address can create another connectivity problem or an address conflict.
3. Check Whether the Default Gateway Is Reachable
The default gateway provides a route to networks outside the local subnet when no more specific route applies.
First, identify the expected gateway from the device's configuration. You can then test basic reachability:
ping <default-gateway-address>
Replace the placeholder with the actual gateway address.
A successful response provides evidence that the device can exchange ICMP packets with that address. It does not prove that DNS, internet access, or the business application is functioning.
Likewise, a failed ping does not automatically prove that the gateway is down. ICMP traffic may be blocked, or the gateway may be configured not to respond to echo requests.
Interpret the result alongside other evidence, such as the device's address configuration, switch or access-point status, and other clients' behavior.
This is an important troubleshooting principle: a test result tells you something specific, not everything about the network.
4. Separate DNS Problems from Connectivity Problems
Sometimes the network connection works, but a device cannot translate a hostname into the address required to reach a service.
This is where DNS testing becomes useful.
For example, try a lookup for the hostname of the affected application:
nslookup portal.example.com
The hostname here is illustrative; use the actual hostname in the environment being investigated.
Check whether the response matches the expected DNS configuration. If the lookup fails, investigate the configured resolver, the DNS record, and whether the client is using the correct internal or external DNS service.
If the hostname resolves correctly, continue investigating. A successful DNS lookup does not guarantee that the destination server is reachable or that the application is accepting connections.
Consider these outcomes:
The hostname does not resolve: Investigate name resolution, DNS server availability, and the relevant record.
The hostname resolves to an unexpected address: Verify the expected record, resolver, and any relevant split-DNS configuration.
The hostname resolves correctly, but the application still fails: Check routing, access controls, the destination service, and the application itself.
This step separates one possible cause from several others, rather than treating every error as a general internet problem.
5. Investigate the Route and the Target Service
If the device has a valid address, can reach its local network, and resolves the destination correctly, investigate the path to the service.
On Windows, you can examine the route taken toward a destination with:
tracert portal.example.com
On systems where the command is available, traceroute provides a similar diagnostic function.
The output can help identify where responses stop or latency increases. However, some routers do not respond to the probes used by traceroute, so an unanswered hop is not conclusive evidence of a broken route.
When the target is a web application, it can also be helpful to test the required TCP port from an authorized client. In Windows PowerShell, for example:
Test-NetConnection portal.example.com -Port 443
This checks whether a TCP connection can be established to the specified host and port. It does not by itself verify that the application is healthy or that a complete TLS and HTTP exchange will succeed.
If the network path and TCP connection appear functional but the application still fails, investigate possibilities such as proxy configuration, firewall rules, certificate issues, authentication failures, or an application-side outage.
Each additional test should answer a specific question.
6. Use the Pattern of Symptoms to Narrow the Cause
The following quick reference can help organize the investigation.
| Observed symptom | Useful next checks |
|---|---|
| Only one device is affected | Client IP settings, adapter, wireless association, local firewall, VPN, or proxy |
| Several devices cannot obtain valid IP addresses | DHCP service, address-pool availability, VLAN assignment, relay configuration |
| Local network works, but several devices cannot reach external networks | Default route, edge firewall, NAT, WAN connection, or upstream service |
| Hostname lookup fails while other connectivity works | DNS resolver, record, or client DNS configuration |
| Only one application fails | Application health, destination port, proxy, TLS certificate, authentication, or application-specific access controls |
| Connection works but performance is poor | Signal quality, interference, congestion, latency, packet loss, and interface errors |
These are starting points, not automatic diagnoses. Real environments can exhibit several faults at once, and each conclusion should be supported by evidence.
7. Make One Controlled Change at a Time
Once you have enough evidence to support a likely cause, develop a corrective action.
Imagine that the investigation reveals that a laptop is receiving the wrong network configuration because it has connected to an unintended network segment.
Changing unrelated DNS, firewall, and adapter settings at the same time would make it difficult to determine which change helped.
Instead, document the suspected cause, identify the appropriate corrective action, consider potential side effects, and obtain the required approval before modifying managed infrastructure.
Make the change within the organization's policies. Keep a record of the previous configuration where appropriate, and ensure you have a rollback plan for changes that could disrupt service.
Then repeat the relevant tests.
A successful correction should address the original symptom without creating a new problem elsewhere in the network.
8. Verify the Result and Document What Happened
Don't close a ticket just because a device appears connected again.
Repeat the tests that demonstrated the original fault. Confirm that the user can access the affected service and check whether other relevant connectivity functions remain healthy.
Record the important details:
- The original symptoms and affected devices.
- The network segment and configuration examined.
- The tests performed and their results.
- The confirmed or most likely cause.
- The corrective action and its outcome.
- Any remaining limitations or follow-up work.
Remove or redact credentials, authentication tokens, and other sensitive details before sharing diagnostic evidence.
Good documentation makes the issue easier to investigate if it returns and helps another technician understand why you made a particular change.
How This Relates to CompTIA Network+
CompTIA Network+ N10-009 covers networking concepts, implementation, operations, security, and troubleshooting. The published exam objectives allocate 24% of the examination to Network Troubleshooting.
The official objectives describe a method that begins with identifying the problem, establishing and testing a theory, planning and implementing a solution, verifying functionality, and documenting the outcome.
This article's workflow applies that reasoning to a realistic connectivity scenario.
You can review the official CompTIA Network+ certification information and the published N10-009 exam objectives to understand the complete set of assessed skills.
For additional reading, EvolveSkill4 also publishes a comparison of CompTIA A+ and Network+ for readers deciding which certification best fits their current experience and career direction.
Final Takeaway
When a device reports that it is connected but an application will not load, avoid assuming that the router is responsible.
Define the scope, check the client configuration, test the gateway, verify name resolution, examine the network path, and investigate the target service. Use each result to decide what to check next.
The best troubleshooting process is not the one that uses the most commands. It is the one that identifies the cause with the least unnecessary disruption and leaves behind enough evidence for someone else to understand the result.
Observe first. Test a theory. Change deliberately. Verify the outcome.
Disclosure: EvolveSkill4 is an independent certification-resource provider. This article is educational and is not affiliated with or endorsed by CompTIA.
