Troubleshooting the Praxis collector on Windows

Use this guide when the Praxis collector on a Windows host is not sending data to your destinations, or has lost its connection to the Praxis backend.

Work through the steps in order. Most issues are caught in Step 1 (network) or Step 2 (service state)—please run these before opening a support ticket, and include the results if you still need help.

All commands below are for PowerShell (run as Administrator).

How the collector connects

The collector makes an outbound HTTPS connection (TCP 443) to the Praxis backend. It uses that connection to receive its configuration and to send your telemetry. The connection is outbound only—no inbound ports need to be opened on the host.

If the host cannot reach the Praxis backend on TCP 443, both configuration updates and data delivery stop.

:::note Use your backend host The examples use praxis.netenrich.com. If your environment was given a different Praxis backend host during installation, substitute it wherever it appears below. :::

Step 1 — Verify network reachability

:::warning ping is not a reliable test ping uses ICMP, which many corporate firewalls block even when HTTPS is fully allowed. A failed ping does not prove the collector is broken, and a successful ping does not prove it can connect. Always finish with the TCP 443 test in Step 1c—that is the check that matters. :::

1a. Does DNS resolve the hostname?

Resolve-DnsName praxis.netenrich.com

You should get back one or more IP addresses. If this fails, it is a DNS/network configuration issue—check the host's configured DNS servers.

1b. Quick reachability look (optional)

ping praxis.netenrich.com

If it replies, good. If it times out, do not conclude the collector is broken—continue to Step 1c.

1c. The real test — can it reach the backend on port 443?

This is the definitive check.

Test-NetConnection praxis.netenrich.com -Port 443

TcpTestSucceeded : True means the path is open. False means a firewall or proxy is blocking outbound 443.

For a fuller check including the TLS handshake (Windows 10 / Server 2016 and later include curl.exe):

curl.exe -v https://praxis.netenrich.com

Any HTTP response after a completed TLS handshake means you reached the backend.

1d. If 443 is blocked or a proxy is in the way

• Confirm your firewall allows outbound TCP 443 to the Praxis backend host.
• If your network requires an HTTP proxy for egress, the collector must be configured to use it. A proxy that performs TLS inspection can break the connection with certificate errors—the Praxis certificate must be trusted end to end.
• Allowlist the hostname, not a fixed IP address—the IP can change.

tip

If Step 1 fails, this is a network/firewall change on your side. No collector change will help until outbound 443 to the Praxis backend works.

Step 2 — Is the collector service running?

The collector runs as a Windows service named praxis-collector.

Get-Service praxis-collector

To restart it:

Restart-Service praxis-collector

You can also manage it from the Services console (services.msc).

:::note A restart is often normal The collector may occasionally request its own restart (for example, after a configuration update). Windows relaunches the service automatically—this is expected, not an error. :::

Step 3 — Check the collector logs

Where the logs are

C:\Program Files\Netenrich\PraxisCollector\logs\praxis-collector.log

Tail the log live:

Get-Content 'C:\Program Files\Netenrich\PraxisCollector\logs\praxis-collector.log' -Tail 100 -Wait

Errors and warnings are logged by default, so you can read them directly—no configuration change is needed to see what went wrong.

What the messages mean

What you see	Likely cause
connection refused / connection timed out / no route to host	Network/firewall — return to Step 1
TLS handshake error / certificate signed by unknown authority	TLS-inspection proxy, untrusted certificate, or wrong system clock
Authentication/authorization errors (401 / 403)	Credential issue; the collector may need to be re-enrolled. Note and send to support
context deadline exceeded / request timeouts	Praxis backend unreachable or too slow — usually network
Repeated "reconnecting" / connection-dropped messages	Unstable or filtered network path (often a proxy or load balancer closing idle connections)
no such host	DNS — return to Step 1a

note

The collector reconnects to the Praxis backend automatically if the connection drops. Repeated reconnects usually point to an unstable or filtered network path.

Step 4 — Common causes checklist

Confirm each of these before contacting support:

• Outbound TCP 443 to the Praxis backend is allowed (Step 1c passed).
• DNS resolves the Praxis backend hostname (Step 1a).
• The service is running and not crash-looping (Step 2).
• The system clock is correct / time-synced — a skewed clock breaks secure connections.
• No proxy or TLS-inspection appliance is silently intercepting the connection.
• The host has free disk space for logs and state (a full disk can stall the collector).
• Nothing changed recently on the network (new firewall rule, proxy, VPN, or security policy).

What to send us if you still need help

Fastest option: run the one-command diagnostic collector from an elevated prompt and attach the zip it produces — it gathers everything below (and more) automatically, with secrets redacted.

If you prefer to collect manually, these resolve tickets much faster:

1. Collector version and Windows version.
2. Symptom — "no data at destination" vs. "lost connection to Praxis," and roughly when it started.
3. Step 1 results — output of Resolve-DnsName and Test-NetConnection ... -Port 443.
4. Step 2 result — Get-Service praxis-collector output.
5. Collector logs — the window around the failure (Step 3). Redact any secrets.
6. Network context — any proxy, firewall, VPN, or TLS-inspection between the host and the internet, and any recent changes.