Ping fails but websites work: test TCP 443 separately
Use Test-NetConnection to separate name resolution, TCP connectivity and browser-level HTTPS failures. Compare the observed outcomes to choose the next investigation and preserve the original configuration.
Published · Updated · FaultNote editorial policy
Who this guide is for and what to prepare
- Users investigating inconsistent ping and web behavior
What you need
- Save work and record the time and destination of the symptom
- Record the PC and router models and Windows version
Choose the actual connection
A failed ping alone does not establish an internet outage. Record the affected hostname and browser error. Public HTTPS commonly uses TCP 443; use the documented port for a service with a different configuration.
Run an explicit TCP test
Replace the example hostname with the affected one. Read RemoteAddress, InterfaceAlias, SourceAddress and TcpTestSucceeded. PingSucceeded can be false while TCP succeeds when the two traffic types receive different treatment.
Test-NetConnection www.microsoft.com -Port 443 -InformationLevel DetailedUnderstand the scope of success
A successful TCP test does not validate page rendering, certificates, authentication or downloading. It does not complete the browser workflow. If only the browser fails, inspect its proxy, extensions and exact certificate or page error.
- Identify the service hostname and port. Query the separate download host when that is the failing connection.
- Keep complete details, browser error and time. The selected address and adapter matter in addition to the success flag.
- Test a control on the same port and check VPN state. Label route changes rather than treating the attempts as identical.
- Verify the actual page after TCP success. On failure compare another device and establish scope before investigating settings.
Use a control destination
Run the same test against a site that normally works. Failure for both suggests inspecting the adapter or network; one affected host points toward that service or route. Do not disable a firewall based on one false result.
Inspect the interface and VPN path
Check whether InterfaceAlias matches the intended Ethernet or Wi-Fi path. A work VPN may impose routing policy; follow its administrator rules. For a personal VPN comparison, save active work and test one state at a time with a clear way to reconnect.
A distributed service may return different addresses across attempts. Keep RemoteAddress with each result so you can see whether the peer changed. Entering an IP directly in the browser changes hostname and certificate handling, so it is not an equivalent replacement for the original URL test.
Keep a useful support excerpt
Keep the time, target host, TCP result, selected interface and control result. Preserve both successful and failed attempts to distinguish intermittent behavior from a constant failure. These results do not measure transfer speed.
Scroll horizontally to see the full table →
| Observation | Next action |
|---|---|
| Ping fails, TCP succeeds | Allow for restricted ICMP replies and verify the web workflow. |
| TCP succeeds, certificate fails | Check clock, official hostname and detailed browser error. |
| Only target TCP fails | Compare another device and official service status at the same time. |
Worked example: TCP succeeds but a certificate fails
When TCP succeeds but the browser reports an expired or mismatched certificate, distinguish transport reachability from trusted HTTPS. Check the PC clock and official URL. Bypassing the error to enter credentials is not part of the diagnostic procedure.
Compare another browser and consult the administrator if an organizational proxy is involved. Success in one browser narrows the investigation to the other browser configuration or extensions. For suspected server trouble, compare official status information before changing router ports or resetting the connection.
Escalate a port-specific failure
If control HTTPS works but the target port fails, keep the time, RemoteAddress and port together. Maintenance, access policy and route trouble remain candidates; one failed command does not establish a faulty home router. Another device or authorized connection helps narrow the scope.
For a private service, use only the host and port supplied by its administrator. There is no need to probe many ports on an address. Preserve proxy and VPN state before a change and compare how that one change affects the same intended connection.
Limitations and requirements
- These procedures target home PCs; follow administrator policy on managed devices.
Frequently asked questions
Does TCP success prove downloads work?
No. Authentication, HTTP response, available storage and application behavior still need checking.
Does this command measure speed?
No. It diagnoses connection establishment and related details. Do not report its result as a throughput measurement.
Should I test a home share with port 443?
Ordinary SMB sharing is separate from HTTPS. Use the service documented port or the SMB common-port option for that purpose.
Sources and verification date
Sources checked: . These sources support the specifications, procedures or prices discussed here. Check each source for applicable conditions and current information.
Related practical guides
- Read a Windows Wi-Fi report to correlate intermittent disconnections
- Ethernet connects at 100 Mbps: isolate a low-rate cable or port link
- A single site will not open: compare DNS answers with nslookup
- A 169.254 address on Windows: inspect DHCP and the default gateway
- How to read pathping loss without blaming a silent intermediate router
- Test a read-only Windows home-network share and separate access from permissions