What causes "task trace:%s" in XX-net/XX-Net?

Check network latency to the relay host (ping/mtr) and switch to a closer/faster server in x_tunnel config.

task trace:%s

Error message

task trace:%s

What it means

Logged when an x_tunnel round-trip request completed with RTT greater than 8000ms. It is a warning-level diagnostic that dumps the worker trace and task trace so operators can see where time was spent, and increments the slow_roundtrip statistic. It does not abort the session; the roundtrip data is still processed afterwards.

Source

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

                    self.target_on_roads,
                    speed, roundtrip_time, server_timeout
                )
                if g.config.show_debug:
                    xlog.debug("data:%d ack:%d rcvd_no:%d sent_no:%d unack_sent_no:%d", data_len, ack_len, rcvd_no_len, sent_no_len, unack_snd_sn_len)

                if len(self.conn_list) == 0:
                    self.target_on_roads = 0
                elif len(content) >= g.config.max_payload:
                    self.target_on_roads = \
                        min(g.config.concurent_thread_num - g.config.min_on_road, self.target_on_roads + 10)
                elif data_len <= 200:
                    self.target_on_roads = max(g.config.min_on_road, self.target_on_roads - 5)
                self.trigger_more()
                # xlog.debug("target roundtrip: %d, on_road: %d", self.target_on_roads, self.on_road_num)

                if rtt > 8000:
                    xlog.warn("rtt:%d speed:%d trace:%s", rtt, speed, response.worker.get_trace())
                    xlog.warn("task trace:%s", response.task.get_trace())
                    g.stat["slow_roundtrip"] += 1

                data = payload.get_buf(data_len)
                ack = payload.get_buf(ack_len)
                rcvd_no_list = payload.get_buf(rcvd_no_len)
                sent_no_list = payload.get_buf(sent_no_len)
                unack_snd_sn = payload.get_buf(unack_snd_sn_len)
                ext = payload.get_buf(ext_len)

                if len(payload) > 32:
                    checksum_str = utils.to_str(payload.get(32).tobytes())
                    checksum = hashlib.md5(bytes(content[:-32])).hexdigest()
                    if checksum != checksum_str:
                        xlog.warn("checksum error:%s %s", checksum_str, checksum)

                        data_info["stat"] = "timeout"
                        continue

View on GitHub (pinned to cfa5bc17b6)

Solutions

Check network latency to the relay host (ping/mtr) and switch to a closer/faster server in x_tunnel config.
Inspect the printed task/worker trace to identify which hop (connect, TLS, upload, download) consumed the time.
If persistent, reduce target_on_roads / concurrency settings or restart the session to re-select a server.
Check g.stat['slow_roundtrip'] growth rate to confirm whether it is transient or systemic.

Defensive patterns

Strategy: retry

Prevention

Monitor g.stat['slow_roundtrip'] and alert when it grows steadily.
Prefer low-latency relay servers in x_tunnel config.
Warm up/health-check sessions before sending time-sensitive traffic.

When it happens

Trigger: A roundtrip_task in x_tunnel/local/proxy_session.py finishes with rtt > 8000 (milliseconds) after receiving the response from the remote worker. Typical causes are a congested relay, a slow proxy target, or TCP links with high latency/loss.

Common situations: Users behind slow or lossy networks (cross-country relays, mobile links), an overloaded XX-Net relay server, or a target site that is itself slow. Also seen when the local network path throttles the tunnel connection.

Related errors

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