What causes "report fail." in XX-net/XX-Net?

Treat single failures as transient — the reporter retries on its next cycle; watch for consecutive failures.

report fail.

Error message

report fail.

What it means

check_report_status periodically POSTs usage stats to the x-tunnel server via call_api('/report_stat', ...). If call_api returns a falsy status (network error, HTTP failure, or API-level error), it logs 'report fail.' and returns, skipping the update of last_state and the server-provided IP list (tls_relay_front.set_ips).

Source

Thrown at code/default/x_tunnel/local/proxy_session.py:276

        stat["version"] = g.xxnet_version
        stat["client_uuid"] = g.client_uuid
        timeout_count = g.stat["timeout_roundtrip"] - self.last_state["timeout"]
        if timeout_count == 0:
            return

        stat["global"]["timeout"] = timeout_count
        stat["global"]["ipv6"] = check_local_network.IPv6.is_ok()
        stat["tls_relay_front"]["ip_dict"] = g.tls_relay_front.ip_manager.ip_dict

        report_dat = {
            "account": str(g.config.login_account),
            "password": str(g.config.login_password),
            "stat": stat,
        }
        xlog.debug("start report_stat")
        status, info = call_api("/report_stat", report_dat)
        if not status:
            xlog.warn("report fail.")
            return

        self.last_state["timeout"] = g.stat["timeout_roundtrip"]
        data = info["data"]
        g.tls_relay_front.set_ips(data["ips"])

    def get_stat(self, type="second"):
        self.traffic_speed_calculation()

        res = {}
        rtt = 0
        recent_sent = 0
        recent_received = 0
        total_sent = 0
        total_received = 0
        for front in g.http_client.all_fronts:
            if not front:
                continue

View on GitHub (pinned to cfa5bc17b6)

Solutions

Treat single failures as transient — the reporter retries on its next cycle; watch for consecutive failures.
Verify outbound HTTPS connectivity to the x-tunnel API host (curl the /report_stat endpoint).
Restart the tunnel if failures persist, which re-logins and refreshes credentials.
Check server status pages/maintenance windows if all clients report failure.

Defensive patterns

Strategy: retry

Prevention

Let the periodic reporter retry; alert only on consecutive failures.
Keep outbound HTTPS to the API host unblocked (no TLS MITM).
Restart the tunnel after long offline periods to refresh credentials.

When it happens

Trigger: The scheduled reporter thread calling /report_stat while the API endpoint is unreachable, returns 5xx, or the response fails validation, so call_api yields status=False.

Common situations: Transient Internet outages; API server maintenance; DNS issues; TLS interception middleboxes breaking the API call; long-running process where the auth cookie/token expired.

Related errors

AI-assisted analysis of XX-net/XX-Net@cfa5bc17b6 (2026-08-27). Data as JSON: /api/errors/db0e209791ea6499. Report an issue: GitHub.