What causes "timeout_checker found transfer_no:%d timeout:%f" in XX-net/XX-Net?

Increase g.config.send_timeout_retry (and/or send_timeout) to comfortably exceed your worst-case round-trip time.

timeout_checker found transfer_no:%d timeout:%f

Error message

timeout_checker found transfer_no:%d timeout:%f

What it means

The background timeout_checker thread scans transfer_list and marks a round-trip transfer as 'timeout' when the elapsed time since start_time exceeds the transfer's server_timeout plus g.config.send_timeout_retry. The warn reports how long the transfer has been in flight; afterwards target_on_roads is increased and trigger_more() is called to pump more transfers.

Source

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

                    continue

                self.round_trip_thread[i] = threading.Thread(target=self.normal_round_trip_worker, args=(i,),
                                                             name="roundtrip_%d" % i)
                self.round_trip_thread[i].start()

            self.connection_pipe.start()
            xlog.info("session started.")
            return True

    def timeout_checker(self):
        while self.running:
            timeout_num = 0
            with self.lock:
                time_now = time.time()
                for sn, data_info in self.transfer_list.items():
                    if data_info["stat"] != "timeout" and time_now - (data_info["start_time"] + data_info["server_timeout"]) > g.config.send_timeout_retry:
                        data_info["stat"] = "timeout"
                        xlog.warn("timeout_checker found transfer_no:%d timeout:%f", sn, time_now - data_info["start_time"])
                        timeout_num += 1

            if timeout_num:
                self.target_on_roads = \
                    min(g.config.concurent_thread_num - g.config.min_on_road, self.target_on_roads + timeout_num)
                self.trigger_more()

            time.sleep(1)

    def traffic_speed_calculation(self):
        now = time.time()
        time_go = now - self.last_traffic_reset_time
        if time_go > 0.5:
            self.upload_speed = (self.traffic_upload - self.last_traffic_upload) / time_go
            self.download_speed = (self.traffic_download - self.last_traffic_download) / time_go

            self.last_traffic_reset_time = now
            self.last_traffic_upload = self.traffic_upload

View on GitHub (pinned to cfa5bc17b6)

Solutions

Increase g.config.send_timeout_retry (and/or send_timeout) to comfortably exceed your worst-case round-trip time.
Check network quality (packet loss, RTT) to the relay/server and switch to a closer front IP.
If widespread and persistent, check server status; the transfers will be retried automatically.
Reduce offered load (concurent_thread_num) if you are saturating an uplink.

Example fix

# before
send_timeout_retry = 2

# after
send_timeout_retry = 8

Defensive patterns

Strategy: retry

Prevention

Set send_timeout_retry well above measured worst-case RTT.
Monitor transfer_list timeout rates as a network-quality signal.
Prefer closer/lower-loss relay front IPs.

When it happens

Trigger: Normal operation under packet loss, a stalled connection, or an overloaded/slow x-tunnel server so that a round trip is not acknowledged within server_timeout + send_timeout_retry seconds.

Common situations: Lossy or high-latency networks (mobile, cross-continent relays); server temporarily overloaded; send_timeout_retry configured too low for the actual RTT; transient Internet route flaps.

Understand the failure class

Timeouts: ETIMEDOUT, deadlines, and hung requests — what actually expires when a request times out.

Related errors

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