XX-net/XX-Net · warning

get_front_time: %f for %s %s %s

Error message

get_front_time: %f for %s %s %s

What it means

Warns that acquiring a front took longer than 100ms inside front_dispatcher.request(). Not a failure by itself; it indicates front scoring/lock contention or the front pool being busy re-checking dead fronts.

Source

Thrown at code/default/x_tunnel/local/front_dispatcher.py:173

    return num


def request(method, host, path="/", headers={}, data="", timeout=100):
    # xlog.debug("front request %s timeout:%d", path, timeout)
    start_time = time.time()

    content, status, response = "", 603, {}
    while time.time() - start_time < timeout:
        start_get_front = time.time()
        front = get_front(host, timeout)
        if not front:
            xlog.warn("get_front fail")
            return "", 602, {}

        finished_get_front = time.time()
        get_front_time = finished_get_front - start_get_front
        if get_front_time > 0.1:
            xlog.warn("get_front_time: %f for %s %s %s", get_front_time, method, host, path)

        if host == "dns.xx-net.org" and front == cloudflare_front and g.server_host:
            # share the x-tunnel connection with dns.xx-net.org
            # x-tunnel server will forward the request to dns.xx-net.org
            if g.server_host:
                host = g.server_host

        headers["X-Async"] = "1"
        if len(data) < 84:
            padding = utils.to_str(utils.generate_random_lowercase(random.randint(8, 64)))
            headers["Padding"] = padding

        content, status, response = front.request(
            method, host=host, path=path, headers=dict(headers), data=data, timeout=timeout)

        if status not in [200, 521, 400, 404]:
            xlog.warn("front retry %s%s", host, path)
            time.sleep(1)

View on GitHub (pinned to cfa5bc17b6)

Solutions

1. Reduce concurrency or accept the latency warning
2. Ensure working fronts exist so get_front isn't rechecking dead ones
3. Check the front statistic thread logs for why fronts are unhealthy

When it happens

Trigger: get_front() blocking >0.1s: many fronts in re-check backoff, lock contention with the statistics thread, or a large front list being iterated while threads contend.

Common situations: Heavy concurrency through x-tunnel local proxy while fronts are mostly dead; low-end hardware; statistics thread updating scores.

Related errors

• get_front fail
• front retry %s%s
• XTunnelNotRunning
• ConnectionPipe remove sock e:%r
• proxy handler read error %r

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