## Intro When a service stops responding or a deployment fails, network issues are often the first suspect. PowerShell gives you a powerful, scriptable way to investigate without installing extra tools. This article shows you how to use PowerShell for network troubleshooting with practical examples: checking DNS resolution, testing ports and connectivity, tracing routes, and diagnosing common failures. We focus on real-world scenarios for developers, DevOps consultants, and startup teams. Each section includes commands, expected output, failure signals, and recovery steps. The goal is operational safety: observe before changing, limit blast radius, and verify results. ## Version and Environment Inventory Before troubleshooting, know what you are working with. Check your PowerShell version and basic system info. ### Check PowerShell Version $PSVersionTable.PSVersion Expected output (example): Major Minor Build Revision ----- ----- ----- -------- 7 4 6 0 If you see version 5.1 or lower, some cmdlets like Test-NetConnection may behave differently. Consider updating to PowerShell 7 for better cross-platform support. ### Gather Network Adapter Info Get-NetAdapter | Format-Table Name, Status, LinkSpeed, MacAddress Look for the adapter status to be "Up" and link speed to match your expected network (e.g., 1 Gbps). If status is "Disabled" or "Disconnected", that is your starting point. ### Check IP Configuration Get-NetIPConfiguration | Format-List InterfaceAlias, IPv4Address, IPv4DefaultGateway, DNSServer Verify the IP address is in the expected subnet and the default gateway is reachable. A missing default gateway often explains "no internet" issues. Pitfall: Running these commands without admin rights may hide some information. Open PowerShell as Administrator when troubleshooting adapters or firewall rules. ## Safe Configuration Path Always record the current state before making changes. Use read-only commands first, and make one small change at a time. ### DNS Client Configuration To see current DNS settings: Get-DnsClientServerAddress -InterfaceAlias "Ethernet" | Format-Table If you need to set a specific DNS server (e.g., for testing), note the current value, then change it: Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses ("8.8.8.8", "1.1.1.1") Verification: Run Resolve-DnsName example.com and confirm it resolves. Recovery: To revert, run the same command with the original DNS server addresses. ### Firewall Rule Check Before modifying firewall rules, list existing rules for a specific port or program: Get-NetFirewallRule -DisplayName "*HTTP*" | Format-Table DisplayName, Enabled, Direction, Action If a rule is missing or blocking, create a new rule carefully: New-NetFirewallRule -DisplayName "Allow Port 8080" -Direction Inbound -Protocol TCP -LocalPort 8080 -Action Allow Always test after adding the rule and remove it if not needed. Pitfall: Broadly disabling the firewall to "see if it works" is dangerous. Instead, create a narrow rule and verify. ## Verification and Diagnostics This section covers the most common network troubleshooting tasks: DNS, ports, connectivity, and route tracing. ### DNS Resolution with Resolve-DnsName Use Resolve-DnsName to check if a hostname resolves and to what IP address. Resolve-DnsName www.google.com Expected output snippet: Name Type TTL Section IPAddress ---- ---- --- ------- --------- www.google.com A 300 Answer 142.250.72.4 If you get no answer or an error, the DNS server may be unreachable or the domain may not exist. Try querying a specific DNS server: Resolve-DnsName www.google.com -Server 8.8.8.8 If that works, your configured DNS server is the issue. Change it or flush the DNS cache: Clear-DnsClientCache Pitfall: Negative caching can cause temporary failures. Clear-DnsClientCache often helps. ### Testing Ports with Test-NetConnection Test-NetConnection is a versatile cmdlet for ping, port testing, and route tracing. Ping a host: Test-NetConnection www.google.com Output includes PingSucceeded and RemoteAddress . If ping fails but you suspect ICMP is blocked, test a specific TCP port: Test-NetConnection www.google.com -Port 443 If TcpTestSucceeded is True, the port is open. If False, the port is closed or filtered. Pitfall: Test-NetConnection can be slow because it does a reverse DNS lookup. For faster port checks, use the .NET TcpClient method: $client = New-Object System.Net.Sockets.TcpClient $client.Connect("www.google.com", 443) $client.Connected $client.Close() ### Checking Connectivity with Test-Connection For quicker ping tests, use Test-Connection : Test-Connection -ComputerName 8.8.8.8 -Count 2 This sends two ICMP echo requests and returns StatusCode 0 if successful. ### Tracing Route with tracert or Test-NetConnection To see the path packets take: tracert 8.8.8.8 Or using PowerShell: Test-NetConnection 8.8.8.8 -TraceRoute Look for where the trace stops or shows high latency. That indicates a routing issue or firewall block along the path. ### Examining Open Ports on Local Machine Use Get-NetTCPConnection to see listening ports and established connections: Get-NetTCPConnection -State Listen | Sort-Object LocalPort | Format-Table LocalAddress, LocalPort, OwningProcess Identify if your application is actually listening on the expected port. If not, the service may not be started or is configured incorrectly. ## Failure Modes and Recovery Common network failures and how to recover from them. ### DNS Resolution Fails Symptoms: Resolve-DnsName returns an error or no answer. Possible causes: DNS server down, incorrect DNS server configured, domain does not exist, local DNS cache corrupted. Recovery steps: - Check DNS server address: Get-DnsClientServerAddress . - Try resolving with a public DNS: Resolve-DnsName example.com -Server 8.8.8.8 . - Clear DNS cache: Clear-DnsClientCache . - If still failing, check network adapter status and restart DNS client service (requires admin): Restart-Service -Name Dnscache . ### Port Connection Refused or Timeout Symptoms: Test-NetConnection shows TcpTestSucceeded: False or connection times out. Possible causes: Service not running, firewall blocking, wrong port, host unreachable. Recovery steps: - Verify service is running: Get-Service -Name . - Check listening ports: Get-NetTCPConnection -State Listen . - Check firewall rules: Get-NetFirewallRule and ensure allow rule exists for that port. - Try connecting from another machine to isolate if it's a local firewall issue. ### Intermittent Connectivity Symptoms: Pings succeed sometimes, fail other times; packets lost. Possible causes: Network congestion, faulty cable, duplicate IP, wireless interference. Recovery steps: - Run continuous ping to see pattern: ping -t 8.8.8.8 (stop with Ctrl+C). - Check network adapter errors: Get-NetAdapterStatistics . - Update network driver: Get-NetAdapter | Format-List Name, DriverVersion, DriverDate and compare with manufacturer's latest. - Check for IP conflicts: Get-NetIPAddress | Format-Table IPAddress, InterfaceAlias, PrefixLength and ensure unique IPs. ## Operations Checklist Use this checklist to systematically troubleshoot network issues with PowerShell. Replace placeholders with your specific values.
StepCommandExpected ResultIf Fails
Check PowerShell version$PSVersionTable.PSVersionVersion 5.1 or laterUpgrade PowerShell
Check network adapter statusGet-NetAdapterStatus UpEnable adapter or check cable
Check IP configurationGet-NetIPConfigurationValid IP, gateway, DNSRenew DHCP or set static IP
Test DNS resolutionResolve-DnsName google.comReturns IP addressCheck DNS server, clear cache
Test connectivity to gatewayTest-Connection -ComputerName <gateway IP>Ping succeedsCheck local network, cable, switch
Test port to remote hostTest-NetConnection <host> -Port <port>TcpTestSucceeded TrueCheck remote service, firewall rules
Check listening portsGet-NetTCPConnection -State ListenExpected port listed with process IDStart service or fix application config
Trace routetracert <destination>Route completes to destinationIdentify where trace stops, check routing/firewall
Owner: Assign one person to be responsible for network troubleshooting (e.g., network administrator or DevOps lead). They should review network configuration changes monthly and after any major deployment. ## Common Pitfalls and How to Avoid Them - Running commands without admin rights - Many network cmdlets require elevation. Always run PowerShell as Administrator when changing settings or viewing detailed info. - Not verifying current state before changes - Always run read-only commands first and save the output. If something goes wrong, you can revert. - Broad firewall changes - Instead of disabling the firewall, create narrow rules for specific ports and protocols. - Using outdated cmdlets - For example, Test-Connection replaced ping . Use modern cmdlets for better scripting. - Ignoring DNS negative caching - After fixing a DNS issue, clear the cache to avoid stale results. - Assuming a single point of failure - Network issues can be layered (DNS, routing, firewall, application). Test each layer systematically. ## Conclusion PowerShell provides a robust set of tools for network troubleshooting, from DNS resolution to port testing and route tracing. By following the practical examples and checklist in this article, you can diagnose and resolve most common network issues efficiently. Start with a low-risk verification: check your network adapter status and DNS resolution. Record the current state, run the commands, and compare the results. If you encounter failures, use the recovery steps to get back online. Always document what you changed so that others can learn and roll back if needed. Remember, the key to effective troubleshooting is to observe first, change one thing at a time, and verify each step. With PowerShell, you have the power to make network diagnostics scriptable, repeatable, and safe.