Skip to main content

Troubleshooting the Praxis collector on Linux

Use this guide when the Praxis collector on a Linux 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.

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 / TLS test in Step 1c—that is the check that matters. :::

1a. Does DNS resolve the hostname?​

nslookup praxis.netenrich.com

You should get back one or more IP addresses. If this fails, it is a DNS/network configuration issue—check /etc/resolv.conf, your internal DNS server, or split-horizon DNS.

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 over TLS on port 443?​

This is the definitive check.

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

Look for a completed TLS handshake (SSL connection using TLS...) and any HTTP response—that means you reached the backend. Connection refused, Connection timed out, or Could not resolve host indicates a network/firewall/DNS problem.

If curl is unavailable:

openssl s_client -connect praxis.netenrich.com:443

You should see a certificate chain. A hang or immediate close means port 443 is blocked.

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

  • Confirm your firewall / security group 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 systemd service named praxis-collector.

systemctl status praxis-collector

To restart it:

sudo systemctl restart praxis-collector

:::note A restart is often normal If the logs show the service exiting with code 75, that is the collector requesting its own restart (for example, after a configuration update). systemd relaunches it automatically—this is expected, not an error. :::

Step 3 — Check the collector logs​

Where the logs are​

  • Log file: /var/log/praxis-collector/praxis-collector.log
  • Or via the system journal: journalctl -u praxis-collector -e

Tail the log live:

tail -f /var/log/praxis-collector/praxis-collector.log

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 seeLikely cause
connection refused / connection timed out / no route to hostNetwork/firewall — return to Step 1
TLS handshake error / certificate signed by unknown authorityTLS-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 timeoutsPraxis backend unreachable or too slow — usually network
Repeated "reconnecting" / connection-dropped messagesUnstable or filtered network path (often a proxy or load balancer closing idle connections)
no such hostDNS — 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 / NTP-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​

Collecting these upfront resolves tickets much faster:

  1. Collector version and Linux distribution/version.
  2. Symptom — "no data at destination" vs. "lost connection to Praxis," and roughly when it started.
  3. Step 1 results — output of the DNS and curl port-443 tests.
  4. Step 2 result — systemctl status 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.