# Connectivity and paths

> Path priority, link-state inspection, and cloud relay configuration and availability.

Source: https://www.widewired.com/page/docs/paths

## Path selection order

A device link considers paths in this fixed order:

1. **Direct**: an end-to-end encrypted connection between the devices. Free.
2. **Peer relay**: forwarded through another device in the same network. Free.
3. **Cloud relay**: forwarded over WideWired's backbone. Metered by successfully forwarded traffic.

A disabled path is excluded. When link quality changes, the system reselects automatically.

## Direct connectivity requirements

Devices behind NAT probe mutually reachable addresses and attempt traversal. Direct commonly fails when:

- both sides are behind symmetric NAT;
- an intermediate network blocks UDP;
- a corporate firewall permits only specific outbound ports.

Falling back to a relay is normal path selection. Traffic remains end-to-end encrypted, and a relay cannot read the payload.

## Inspecting the current path

```
wwnet
```

The status table prints one `peers` row per peer, in the form
`<name> (<network address>) - <path type>, <state>`. The path type is `direct`,
`peer relay` or `cloud relay`; the state is `healthy`, `needs attention` or `checking`.

In the console:

- **Configuration → Links** shows current path, quality and policy per link.
- **Overview** uses the network topology and link styles to show the current channel.
- **Insights → Traffic** and **Insights → Quality** show historical flows, directional RTT/loss and path transitions.

## Configuring cloud relay

Under **Configuration → Links**, configure each link's:

- **Time plan**: when cloud relay is allowed. No plan means always allowed; an empty grid means always prohibited. The selected timezone applies.
- **Path policy**: a preset or custom thresholds controlling reselection.

Cloud relay is the only metered path; see the [billing model](https://www.widewired.com/page/docs/billing-model).

## Verifying a link

Confirm that both endpoints report `status connected`, then reach the peer's network address:

```
ping <peer overlay IP>
```

To separate network-layer reachability from an application-port issue, test the relevant TCP or UDP port afterwards.

## Quick troubleshooting

| Symptom | Check and action |
| --- | --- |
| A relay is used instead of direct | Check NAT type, outbound UDP policy and host firewalls; relay fallback itself is not a fault |
| Cloud relay says credit is initializing | Wait for balance sync and refresh |
| Cloud relay says credit is exhausted | Top up; direct and peer relay remain available |
| Cloud relay says the schedule is inactive | Check the plan, timezone and current time |
| Cloud relay says the region is unknown | The rate cannot yet be selected; wait for recovery and contact support if it persists |
| Cloud relay says the relay is unavailable | Check free paths; cloud relay rejoins selection automatically after recovery |
| `ping` fails while the path is healthy | Check whether the target firewall allows ICMP on the virtual adapter, then test the application port |