Decentralized Privacy Node Operations and Health Checks

This guide explains how operators and engineers should think about AeroNyx decentralized privacy node health. The goal is to make node operation reliable without exposing user content or private routing data.

Core health layers

Layer	What it proves
Service health	The decentralized node process is running and responding.
Privacy transport health	The encrypted privacy-network data plane can accept sessions and report aggregate counters.
Peer discovery health	The node knows a bounded set of signed peers and can recover them after restart.
Blind relay health	The node can forward opaque encrypted envelopes without parsing content.
Two-hop path proof health	The node can prove a synthetic entry -> middle -> terminal route shape.
Backend heartbeat health	The node is reporting aggregate operational status to AeroNyx backend APIs.

Recommended operator workflow

Open Nodeboard at https://app.aeronyx.network, choose a node, and check:

Protocol health - service, heartbeat freshness, transport state, and aggregate counters.
Discovery - peer counts, valid peers, gossip freshness, restart recovery, and rejected descriptor counters.
Relay foundation - blind relay status, routeability, abuse guard, and proof readiness.
Capacity - IP pool capacity, session limits, file descriptors, conntrack pressure, packet drops, pps, and bps.
Incidents - recent events, command audit state, and closure evidence after restart or upgrade.

Two-hop path proof checks

The decentralized node now exposes display-ready two-hop proof quality fields:

json

{
  "status": "ready",
  "proof_ready": true,
  "recent_success_ready": true,
  "failure_streak_active": false,
  "stale_after_seconds": 1800,
  "next_action": "continue monitoring repeated two-hop path proof freshness"
}

Operators should interpret these fields as follows:

Field	Healthy value	Action if unhealthy
`status`	`ready`	Read `next_action`; inspect discovery and routeability.
`proof_ready`	`true`	Wait for a fresh proof or check peer routeability.
`recent_success_ready`	`true`	Confirm gossip freshness and route candidate health.
`failure_streak_active`	`false`	Investigate middle-hop endpoint, terminal-hop proof bucket, and abuse guard counters.
`stale_after_seconds`	positive freshness window	Do not display stale proof as live readiness.

Public network stats

The public aggregate endpoint exposes fleet-level privacy-safe status:

text

GET https://api.aeronyx.network/api/privacy_network/vpn/public/network-stats/

Relevant object:

text

data.protocol_status.protocol_foundation.two_hop_path_proof_history

Example healthy aggregate:

json

{
  "reported_nodes": 3,
  "proof_ready_nodes": 3,
  "recent_success_ready_nodes": 3,
  "failure_streak_nodes": 0,
  "status_counts": {
    "ready": 3
  }
}

The legacy vpn path remains for API compatibility. Public copy should describe the product as the AeroNyx Privacy Network or AeroNyx Privacy Protocol.

Restart and upgrade checks

After restart or upgrade:

Confirm the service becomes active.
Confirm heartbeat freshness in Nodeboard.
Confirm peer cache recovery.
Confirm discovery stage returns to a ready state.
Confirm two-hop proof status returns to ready.
Confirm no incident remains open without closure evidence.

If active user sessions exist, operators should prefer maintenance mode or a planned window before restart or upgrade.

Privacy rules for operators

Health checks may expose operational counters, but they must not expose:

plaintext messages
encrypted payload bodies
raw route IDs
client public IP activity
DNS contents
browsing domains or URLs
MemChain plaintext
voucher secrets
wallet-level traffic
social graph edges

The operator experience should feel rich and commercial while preserving the blind-node invariant.