[Bug]: Bug: Bug: Outbound connection test fails when eth0 has no internet and default route is via tun0

[iran100]

Describe the bug

In version 2.9.3, the Outbound connection test worked perfectly and showed the correct latency. However, since upgrading to v3.3.0, the test (for all outbounds like Armenia, SamanTel Socks) always returns "Failed", even though all tunnels and outbound connections are fully functional for clients. This issue only happens because the server architecture routes all internet traffic via a VPN interface (tun0), leaving the primary eth0 interface with no direct internet access.

How to reproduce the problem

1. Set up a VPS where the primary interface (eth0) has no internet connection.
2. Connect the VPS to an OpenVPN client, making tun0 the default route for all traffic.
3. Configure normal inbounds and several healthy outbounds (e.g., Vless, Socks).
4. Go to the panel, click "Test All" (TCP or HTTP).
5. Observe that all outbounds result in "Failed" while clients connecting through those same inbounds/outbounds have internet access.

Expected behavior

I expected the panel's test mechanism to follow the system's default routing table (respecting tun0) and show the correct latency (ms), rather than strict-binding or forcing test packets via the internet-less eth0 interface.

Actual behavior

The panel incorrectly shows "Failed" for all healthy outbound connections because it cannot successfully send test packets via the primary, but internet-less, eth0 interface.

Relevant logs

Screenshots

No response

3x-ui version

3.3.0

Xray-core version

No response

How did you install 3x-ui?

install.sh script

Operating system

Ubuntu 26.04

Which parts of the panel are affected?

No response

Browser (only if it is a UI bug)

No response

Is the panel behind a reverse proxy or CDN?

None

Before submitting

• I searched existing issues and this bug has not been reported.
• I am running the latest released version of 3x-ui (or have verified the bug still exists on it).
• This bug report is written in English.
• I have redacted any sensitive data (tokens, real domains, client UUIDs).

[github-actions]

Thanks for the detailed report and reproduction steps.

What changed between v2.x and v3.x

The outbound test feature was completely rewritten in v3.x. v2.9.3 used a different mechanism; v3.x runs a temporary, standalone xray process just for each test and uses xray's burstObservatory to probe the outbound. The relevant code is in web/service/outbound.go (testOutboundHTTP / testOutboundTCP).

What the two test modes actually do

TCP mode (web/service/outbound.go:219): extracts the proxy server's address:port and dials it with net.DialTimeout. This goes through Go's standard network stack, so it does respect the OS routing table (including tun0 as default route). TCP mode should reach remote proxy servers even when eth0 has no internet.

HTTP mode (web/service/outbound.go:323): starts a temp xray binary, configures a burstObservatory with pingConfig.connectivity = "" (which in xray-core means "skip the connectivity pre-check and proceed directly"), and polls http://127.0.0.1:<random-port>/debug/vars for up to 12 seconds waiting for alive: true.

How to get the real error message

The UI only shows "Failed"; the full reason is in the API response. To capture it:

1. Open browser DevTools → Network tab.
2. Click Test All (or test a single outbound).
3. Find the POST /xray/testOutbound request and read the JSON response body — it contains an "error" field with the actual cause.

Common messages to look for:

• "Xray process exited: ..." — the temp xray binary crashed on start; the message after the colon is the last log line.
• "Xray failed to start metrics listener" — the metrics port never became available within 5 s.
• "Probe timed out — outbound did not become reachable" — the xray process started fine but the probe never returned alive: true within 12 s.
• "All probes failed (last attempt Xs ago)" — xray started, ran the probe, and the probe itself failed.

The exact message will tell us which stage is failing.

Possible causes in your specific setup

A few scenarios that are consistent with eth0-less / tun0-routed VPS:

1. Probe destination blocked on the outbound servers' side: The HTTP test sends a request to https://www.google.com/generate_204 through the outbound. If Google is unreachable from the outbound proxy servers (firewall, geo-block), the probe fails even though clients' general traffic works. Try changing the test URL in Settings → Xray Settings → Outbound Test URL to something reachable from those servers (e.g., http://cp.cloudflare.com/ or any URL that returns 2xx from your outbound servers' egress).

2. WireGuard outbound with noKernelTun: If any outbound under test is WireGuard, the code forces noKernelTun: true in the temp config to avoid creating a second tun device. If the kernel and userspace WireGuard behave differently on your VPS (e.g., different UDP socket binding), the temp process may fail to establish the WireGuard handshake. Try testing a non-WireGuard outbound first to isolate.

3. Timing: The burstObservatory timeout is 5 s per probe. If the round-trip through tun0 + the remote proxy adds enough latency to exceed 5 s, the probe is recorded as failed. You can verify this by checking whether a lower-latency outbound (if any) succeeds.

What to share for further diagnosis

To pinpoint the issue, please provide:

1. The exact "error" field from the API response (DevTools steps above).
2. The protocol of the failing outbounds (VLESS, Socks, WireGuard, etc.).
3. Whether the failure appears in TCP mode, HTTP mode, or both (shown in the "mode" field of the response).
4. The output of journalctl -u x-ui -n 50 --no-pager right after running a test — the temp xray process logs to the same journal.