Browse docs

Policy or routing does not apply

Operate and recover

Troubleshooting policy and routing

Recover when policy changed but traffic still follows the old path, routing never applies, or runtime status stays pending.

Section: Operate and recover
Path: /troubleshooting/policy-and-routing

Good for

Community operators troubleshooting policy, route ownership, or runtime apply state.

What you get

You can verify whether the issue is in route ownership, runtime apply mode, or stale device attachments.

Before you start

Access to the affected workspace or network · Access to the gateway host if route diagnostics are needed

Use this guide when the UI shows a policy change but the live traffic path does not follow it.

Check the runtime apply state first

Review the network runtime status and confirm whether the latest state is:

applied,
pending,
or error.

If the runtime is still pending or error, treat that as the primary problem instead of editing more policy.

Check route ownership and attachments

Confirm that:

the ingress and egress devices still belong to the intended network,
route targets still exist,
no recent workspace or group change detached the route from its owner.

Check the active path on the gateway host

Useful commands on the gateway host:

bash

Nanami docs

ip rule show
ip route show table 200
iptables -t mangle -S NANAMI_ROUTE_MARK

If you are running dry-run mode, confirm that the logs still show the expected dry-run exec traces for the route apply step.

Decide the next move

If the runtime status is error, fix the runtime error first.
If ownership or attachments are stale, repair those references instead of retrying the route blindly.
If DNS is the only symptom left, continue with Troubleshooting DNS runtime.

Next steps

Pick the most useful next step instead of the next random article.

Common issues hub Troubleshooting DNS runtime Architecture overview