Troubleshoot a network problem

No websites open

1. Try two unrelated sites on another device on the same Wi-Fi. If only one device fails, prioritize that device, browser and VPN.
2. If all devices fail, check router indicators and your provider's outage information. Compare an owned wired device to isolate Wi-Fi effects.
3. Record the device address, gateway and DNS configuration. A Wi-Fi connection indicator alone does not establish internet access.

Choose the next step from the result

If another connection works while multiple devices on this one fail, ask about the router-to-provider path. Change one setting at a time and record its previous value.

• IP addresses, IPv4 and IPv6
• DHCP and automatic configuration
• DNS, caching and TTL

Check pages to open next

The IP page shows the public IP and browser information a website sees for this connection. The DNS page looks up a name from the internet side. Neither reads your device or router DNS settings, route or port state.

• Page showing this connection's public IP and browser information
• DNS record lookup page

Only one website fails

1. Record the exact host, path, time and browser error. Distinguish HTTP responses such as 403/404 from name-resolution or connection failures.
2. Compare the same URL in another browser or device and, when permitted, another connection. Check login and source-IP restrictions.
3. For a certificate warning, check the hostname and device clock. Administrators should compare A/AAAA/CNAME records; opening an IP-address URL is not a valid substitute for testing the HTTPS hostname.

Choose the next step from the result

If the same URL fails on another connection, send the URL, time and error to the site administrator. Redact tokens and cookies from screenshots or logs.

• Reading a URL
• HTTP, status codes and redirects
• SSL, TLS and certificates
• DNS, caching and TTL

Check pages to open next

Each page examines the hostname you enter from the internet side. They do not reproduce your own connection's view, a sign-in result, or names that resolve only inside an organization.

• DNS record lookup page

Meetings or video are slow or interrupted

1. Inspect the meeting app's delay, jitter, loss and send/receive statistics. Observe CPU and camera load separately from network symptoms.
2. When possible, pause your own large uploads or sync jobs and compare. Compare wired and Wi-Fi access in the same location; isolate distance or congestion if only wireless suffers.
3. Bandwidth in Mbps and round-trip time in ms measure different things. Use contemporaneous app statistics rather than a download-speed result alone.

Choose the next step from the result

If one app still fails on wired access, check its status and managed traffic policy. Do not start with blanket firewall exposure or an unbounded ping.

• Ping, ICMP and round-trip time
• Port numbers, TCP and UDP
• NAT, NAPT and router DMZ settings

Check pages to open next

The IP page is for noting the public IP and browser information for your record. It is not a jitter test and does not measure delay variation, loss, or ICMP, port and NAT reachability.

• Page showing this connection's public IP and browser information

Only email sending or delivery fails

1. Check whether all or one recipient is affected, whether sending or receiving fails, and whether webmail behaves the same way. Record bounce status and time.
2. Check MX, SPF, DKIM and DMARC for your domain. Obtain the DKIM selector from the signature or sender settings instead of guessing many names.
3. Correct DNS does not exclude authentication, quota, spam-folder or recipient-policy problems. DNS results cannot guarantee inbox delivery.

Choose the next step from the result

Use the email checks below, then provide the bounce code and time to the sending service if needed. Avoid sharing message bodies, passwords or unnecessary recipient details.

• DNS, caching and TTL
• Domain names and management

Check pages to open next

• Email configuration check page for MX, SPF, DKIM and DMARC

Behavior changes only with a VPN

1. Within your organization's rules, compare public IP, device DNS settings and failing URLs before and after connecting. Do not bypass a required VPN or security control.
2. If only internal names fail, ask the administrator about internal DNS and routes. Switching to public DNS may prevent internal names from resolving.
3. For app-specific differences, check proxies, browser DNS and split tunneling. The route to the IP page may differ from another app's route.

Choose the next step from the result

If you are unsure which settings may change, give the VPN administrator times, address families and target names. Do not attach private keys or VPN configuration files.

• VPNs, routes and public IPs
• DNS, caching and TTL
• IP addresses, IPv4 and IPv6

Check pages to open next

Open it to compare the connection information shown before and after connecting. A changed public IP neither proves anonymity nor shows that other applications use the same route.

• Page showing this connection's public IP and browser information

Observe your own device

Windows

Run this in Command Prompt to inspect addresses, gateways and DNS settings per adapter. It does not change the configuration.

ipconfig /all

Microsoft: ipconfig

This example sends four ICMP requests to your own gateway. Replace the example 192.168.1.1 with your actual gateway from the configuration above. Use only a target you are authorized to manage.

ping -n 4 -w 1000 192.168.1.1

No reply can also mean ICMP filtering. Interpret it separately from web or meeting success. Microsoft: ping

Mac

Hold Option while opening the Wi-Fi menu in the menu bar, then open Wireless Diagnostics. It examines Wi-Fi connectivity, not a destination website's TLS or email delivery. Apple: Wireless Diagnostics

Phones and tablets

Within your plan's limits, compare the same URL over Wi-Fi and mobile data. Record VPN or data-saving settings, the affected app and time. Switching to mobile data may incur charges.

View this connection's public IP and browser information

A note for your support contact

Copy this template and fill in the relevant fields. This page does not send it. Share IP addresses and device names only where needed for the support request.

Time and time zone:
Symptom and exact error:
Host and path (exclude secret query values):
Device, OS and app:
Wi-Fi / wired / mobile connection:
Comparison with another device or connection:
VPN or proxy in use (exclude configuration secrets):
Recent settings changed and when:
Checks performed and their results: