MYTHOSAI

Network security / PRACTICAL GUIDE

Test a specific connection with PowerShell

Separate a reachable host from a reachable application port using a focused read-only check.

MythosAI editorial · Prepared 8 October 2026 · 2 min read

Before you start

Windows PowerShell and an explicitly authorised destination and TCP port.

Ask a narrow network question

A computer can respond to ping while rejecting the TCP port an application needs. The reverse can also occur if ping is blocked. Test-NetConnection helps distinguish these cases, but it does not log in, prove a service is trustworthy or identify every reason for failure.

Use the actual service port from its documentation or your approved configuration. Do not sweep arbitrary addresses or test a supplier's service outside the permissions you have.

Compare expected and observed access

  1. Record the source computer, intended destination and expected TCP port. Confirm the destination belongs to a system you are authorised to troubleshoot.
  2. Run one connection test from the source where the problem occurs. Read TcpTestSucceeded separately from any ping result.
  3. If permitted, compare from another authorised source with a known working route. A different result can help identify a source firewall, VPN policy or routing boundary.
  4. At the destination, ask the administrator to check whether the application is listening on the expected address and port. A stopped service and a blocked path can look identical from the client.
powershell
Test-NetConnection -ComputerName 192.0.2.10 -Port 443

The address above is reserved for documentation. Replace it with your actual authorised destination; it is not a public test server and should not be expected to respond.

Verify the application afterwards

A successful TCP handshake shows that something accepted a connection on that route at that moment. Open the genuine application, inspect certificate or authentication errors and confirm the intended workflow. A login failure can remain even after the network path is working.

Avoid turning troubleshooting into exposure

Do not disable every firewall or open the port to the whole internet as the first response to failure. Locate the intended source, destination and rule. Make the narrowest approved change, record the previous state and retest from the affected source.

Keep the evidence usable

Save the command, result, time and source network with private addresses protected from unnecessary disclosure. Also record whether a VPN was connected. A later test on a different network may not reproduce the original condition. Network evidence is strongest when it states exactly which path was tested and what the test can actually establish.

Official references

Consult the current vendor documentation if your version or screen differs.

Documentation-based draft. Commands have not all been executed against the named products in a lab. Validate configuration examples against your installed version before changing a working system.

KEEP LEARNING

Related guides

Network security81

Check what encrypted DNS protects

Separate DNS transport privacy from malware filtering, browser security and VPN behaviour.

2 min read · Free guide
Network security82

Test a free threat-filtering DNS service safely

Use a provider's harmless test domain instead of browsing a real malicious website.

2 min read · Free guide
Network security84

Document a small-business network boundary

Turn a vague trusted network into a list of permitted connections and owners.

2 min read · Free guide