Wi-Fi Is Connected, but the App Won’t Load: A CompTIA Network+ Troubleshooting Walkthrough

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.

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.