diagnose-connectivity

Diagnosing a connection failure

Work from the cheapest, most common cause outward. Most reports resolve in the first two steps, and every step below is a read-only call.

Step 0 — scope it

Ask, or determine from the panel, which of these it is:

• Everyone, everywhere → the core or the box (step 1)
• Everyone on one inbound → the inbound (step 2)
• One client → that client's limits (step 3)
• Everyone, but only for one destination → routing or an outbound (step 4)

get_online_clients answers this immediately: a normal-looking list means the core is up and serving, so skip straight to step 3.

Step 1 — the core and the box

server_status
get_xray_logs count=100

The single most common panel-wide outage is a template that Xray refuses to load: the panel saves it happily, the core then fails to start, and every client drops. get_xray_logs names the offending field. Confirm by comparing what is running with what is saved — get_xray_config reports the running core, get_xray_template the saved document; if the config call fails while the template reads fine, the core is down.

Fix the template and restart_xray. If the panel itself is unreachable, nothing here will answer at all — that is a host or firewall problem, not a config one.

Step 2 — the inbound

get_inbound id=<id>

Check, in this order: enable is true; port is what clients are actually dialling and nothing else took it; expiryTime (Unix milliseconds, 0 = never) has not passed; total (bytes, inbound-wide quota) is not exhausted. A disabled or expired inbound looks exactly like a network failure from the client side.

For a REALITY inbound whose settings are unchanged but which stopped getting through, the camouflage target is the suspect — see the reality-inbound skill.

Step 3 — the client

get_client email="alice"
get_client_traffic email="alice"
get_last_online

Five things disable a client that is otherwise correctly configured: