[GH-ISSUE #3457] xtcp建立了连接，但好像连接又不成功

gitea-mirror commented

2026-05-05 13:46:58 -06:00

Owner

Originally created by @PHCSJC on GitHub (May 29, 2023).
Original GitHub issue: https://github.com/fatedier/frp/issues/3457

Bug Description

试了下新版本的xtcp，提示establishing nat hole connection successful，但后面又报no recent network activity，这是什么原因呢？

frpc Version

0.49.0

frps Version

0.49.0

System Architecture

linux/arm64

Configurations

服务端：

[common]
bind_port = 7000
bind_udp_port = 7001

客户端1（被连接端）：

[common]
server_addr = ****
server_port = 7000

[ssh]
type = xtcp
sk = abcdefg
local_ip = 127.0.0.1
local_port = 22

客户端2（连接端）：

[common]
server_addr = ****
server_port = 7000

[ssh_visitor]
type = xtcp
role = visitor
server_name = ssh
sk = abcdefg
bind_addr = 127.0.0.1
bind_port = 6000

Logs

2023/05/29 17:31:17 [W] [xtcp.go:277] [3708484dddd4b9f9] [ssh_visitor] init tunnel session error: dial quic error: timeout: no recent network activity
2023/05/29 17:31:20 [I] [xtcp.go:237] [3708484dddd4b9f9] [ssh_visitor] nathole prepare success, nat type: EasyNAT, behavior: BehaviorNoChange, addresses: [*.*.*.*:50039 *.*.*.*:50039], assistedAddresses: [192.168.21.1:50039 192.168.168.21:50039 192.168.5.8:50039 172.17.0.1:50039 10.8.0.6:50039]
2023/05/29 17:31:21 [I] [xtcp.go:262] [3708484dddd4b9f9] [ssh_visitor] get natHoleRespMsg, sid [1685352680e79151c3ed4828b9], protocol [quic], candidate address[*.*.*.*:50456], assisted address [192.168.2.31:50456 192.168.168.31:50456], detectBehavior: {Role:receiver Mode:0 TTL:7 SendDelayMs:0 ReadTimeoutMs:5000CandidatePorts:[] SendRandomPorts:0 ListenRandomPorts:0}
2023/05/29 17:31:22 [I] [xtcp.go:273] [3708484dddd4b9f9] [ssh_visitor] establishing nat hole connection successful, sid [1685352680e79151c3ed4828b9], remoteAddr [192.168.168.31:50456]
2023/05/29 17:31:27 [W] [xtcp.go:277] [3708484dddd4b9f9] [ssh_visitor] init tunnel session error: dial quic error: timeout: no recent network activity
2023/05/29 17:31:30 [E] [xtcp.go:150] [3708484dddd4b9f9] [ssh_visitor] open tunnel error: open tunnel timeout

Steps to reproduce

...

Affected area

Docs
Installation
Performance and Scalability
Security
User Experience
Test and Release
Developer Infrastructure
Client Plugin
Server Plugin
Extensions
Others

Originally created by @PHCSJC on GitHub (May 29, 2023). Original GitHub issue: https://github.com/fatedier/frp/issues/3457 ### Bug Description 试了下新版本的xtcp，提示establishing nat hole connection successful，但后面又报no recent network activity，这是什么原因呢？ ### frpc Version 0.49.0 ### frps Version 0.49.0 ### System Architecture linux/arm64 ### Configurations 服务端： ``` [common] bind_port = 7000 bind_udp_port = 7001 ``` 客户端1（被连接端）： ``` [common] server_addr = **** server_port = 7000 [ssh] type = xtcp sk = abcdefg local_ip = 127.0.0.1 local_port = 22 ``` 客户端2（连接端）： ``` [common] server_addr = **** server_port = 7000 [ssh_visitor] type = xtcp role = visitor server_name = ssh sk = abcdefg bind_addr = 127.0.0.1 bind_port = 6000 ``` ### Logs ``` 2023/05/29 17:31:17 [W] [xtcp.go:277] [3708484dddd4b9f9] [ssh_visitor] init tunnel session error: dial quic error: timeout: no recent network activity 2023/05/29 17:31:20 [I] [xtcp.go:237] [3708484dddd4b9f9] [ssh_visitor] nathole prepare success, nat type: EasyNAT, behavior: BehaviorNoChange, addresses: [*.*.*.*:50039 *.*.*.*:50039], assistedAddresses: [192.168.21.1:50039 192.168.168.21:50039 192.168.5.8:50039 172.17.0.1:50039 10.8.0.6:50039] 2023/05/29 17:31:21 [I] [xtcp.go:262] [3708484dddd4b9f9] [ssh_visitor] get natHoleRespMsg, sid [1685352680e79151c3ed4828b9], protocol [quic], candidate address[*.*.*.*:50456], assisted address [192.168.2.31:50456 192.168.168.31:50456], detectBehavior: {Role:receiver Mode:0 TTL:7 SendDelayMs:0 ReadTimeoutMs:5000CandidatePorts:[] SendRandomPorts:0 ListenRandomPorts:0} 2023/05/29 17:31:22 [I] [xtcp.go:273] [3708484dddd4b9f9] [ssh_visitor] establishing nat hole connection successful, sid [1685352680e79151c3ed4828b9], remoteAddr [192.168.168.31:50456] 2023/05/29 17:31:27 [W] [xtcp.go:277] [3708484dddd4b9f9] [ssh_visitor] init tunnel session error: dial quic error: timeout: no recent network activity 2023/05/29 17:31:30 [E] [xtcp.go:150] [3708484dddd4b9f9] [ssh_visitor] open tunnel error: open tunnel timeout ``` ### Steps to reproduce 1. 2. 3. ... ### Affected area - [ ] Docs - [ ] Installation - [ ] Performance and Scalability - [ ] Security - [ ] User Experience - [ ] Test and Release - [ ] Developer Infrastructure - [ ] Client Plugin - [ ] Server Plugin - [ ] Extensions - [ ] Others

gitea-mirror closed this issue

2026-05-05 13:46:59 -06:00

gitea-mirror commented

2026-05-05 13:47:01 -06:00

Author

Owner

@fatedier commented on GitHub (May 29, 2023):

ssh_visitor 加上 protocol = kcp ，换个协议测试一下。

另外，你这两个节点是在一个局域网内？对端的日志也可以发一下，另外也可以把 log_level 改成 trace，贴一下更详细的日志来分析。

@fatedier commented on GitHub (May 29, 2023): `ssh_visitor` 加上 `protocol = kcp` ，换个协议测试一下。另外，你这两个节点是在一个局域网内？对端的日志也可以发一下，另外也可以把 log_level 改成 trace，贴一下更详细的日志来分析。

gitea-mirror commented

2026-05-05 13:47:02 -06:00

Author

Owner

@PHCSJC commented on GitHub (May 30, 2023):

@fatedier 节点不在同一个局域网，不过加了kcp确实可以了，这是为什么呢？把ssh的tcp转成udp？

@PHCSJC commented on GitHub (May 30, 2023): @fatedier 节点不在同一个局域网，不过加了kcp确实可以了，这是为什么呢？把ssh的tcp转成udp？

gitea-mirror commented

2026-05-05 13:47:03 -06:00

Author

Owner

@fatedier commented on GitHub (May 30, 2023):

但是你的对端 IP 显示的看起来是走的局域网。

具体原因需要抓包调试，比较复杂，默认的协议是 QUIC，可选 KCP，理论上是一样的。

@fatedier commented on GitHub (May 30, 2023): 但是你的对端 IP 显示的看起来是走的局域网。具体原因需要抓包调试，比较复杂，默认的协议是 QUIC，可选 KCP，理论上是一样的。

gitea-mirror commented

2026-05-05 13:47:04 -06:00

Author

Owner

@PHCSJC commented on GitHub (May 30, 2023):

知道原因了，我这2台之间有安装zerotier，所以被识别成局域网了

@PHCSJC commented on GitHub (May 30, 2023): 知道原因了，我这2台之间有安装zerotier，所以被识别成局域网了

gitea-mirror commented

2026-05-05 13:47:04 -06:00

Author

Owner

@PHCSJC commented on GitHub (May 30, 2023):

反馈一下效果，就不新开贴了，2个nat4节点，可以穿透成功，试了几次100%成功，在开启keep_tunnel_open = true时，ssh几乎秒连接，未开启keep_tunnel_open需要2，3秒时间连接成功

提个小建议，既然nat4成功率都这么高，能不能把xtcp和tun结合一下？这样就可以替代掉zerotier这些内网穿透的软件了

@PHCSJC commented on GitHub (May 30, 2023): 反馈一下效果，就不新开贴了，2个nat4节点，可以穿透成功，试了几次100%成功，在开启keep_tunnel_open = true时，ssh几乎秒连接，未开启keep_tunnel_open需要2，3秒时间连接成功提个小建议，既然nat4成功率都这么高，能不能把xtcp和tun结合一下？这样就可以替代掉zerotier这些内网穿透的软件了

gitea-mirror commented

2026-05-05 13:47:05 -06:00

Author

Owner

@fatedier commented on GitHub (May 30, 2023):

未开启keep_tunnel_open需要2，3秒时间连接成功

这个只在第一次连接时触发需要等待隧道建立的时间，后续只要网络不出异常，隧道也会一直保持，之后再建立 ssh 连接的话，也会很快。

提个小建议，既然nat4成功率都这么高，能不能把xtcp和tun结合一下？这样就可以替代掉zerotier这些内网穿透的软件了

后面会考虑的，确实之前有一些全端口映射的需求可以用这个方式来解决。

@fatedier commented on GitHub (May 30, 2023): > 未开启keep_tunnel_open需要2，3秒时间连接成功这个只在第一次连接时触发需要等待隧道建立的时间，后续只要网络不出异常，隧道也会一直保持，之后再建立 ssh 连接的话，也会很快。 > 提个小建议，既然nat4成功率都这么高，能不能把xtcp和tun结合一下？这样就可以替代掉zerotier这些内网穿透的软件了后面会考虑的，确实之前有一些全端口映射的需求可以用这个方式来解决。

gitea-mirror commented

2026-05-05 13:47:05 -06:00

Author

Owner

@PHCSJC commented on GitHub (Jun 2, 2023):

继续反馈一下：用ssh挂了几天，发现只要ip不变，就不会断，大佬牛逼plus

@PHCSJC commented on GitHub (Jun 2, 2023): 继续反馈一下：用ssh挂了几天，发现只要ip不变，就不会断，大佬牛逼plus

gitea-mirror commented

2026-05-05 13:47:06 -06:00

Author

Owner

@ppl56 commented on GitHub (Oct 12, 2023):

2023/10/12 11:12:11 [W] [xtcp.go:280] [fa813de5668759ca] [p2p_rtsp_visitor] nathole prepare error: discover error: wait response from stun server timeout
2023/10/12 11:12:19 [I] [xtcp.go:283] [fa813de5668759ca] [p2p_rtsp_visitor] nathole prepare success, nat type: HardNAT, behavior: BehaviorPortChanged, addresses: [117.136.80.60:41398 117.136.80.60:17892], assistedAddresses: [192.168.1.12:61937 192.168.205.1:61937 192.168.214.1:61937 192.168.43.80:61937]
2023/10/12 11:12:21 [I] [xtcp.go:309] [fa813de5668759ca] [p2p_rtsp_visitor] get natHoleRespMsg, sid [1697080337c48449f9aff74430], protocol [quic], candidate address [223.104.242.185:7146 223.104.242.185:22356], assisted address [192.168.1.111:54979 10.0.43.205:54979 192.168.0.1:54979 192.168.184.1:54979 192.168.1.105:54979], detectBehavior: {Role:receiver Mode:1 TTL:7 SendDelayMs:0 ReadTimeoutMs:5000 CandidatePorts:[{From:22346 To:22366}] SendRandomPorts:0 ListenRandomPorts:0}
2023/10/12 11:12:21 [W] [xtcp.go:316] [fa813de5668759ca] [p2p_rtsp_visitor] make hole error: wait detect message error: read udp4 0.0.0.0:61937: wsarecvfrom: The connection has been broken due to keep-alive activity detecting a failure while the operation was in progress.
2023/10/12 11:12:26 [E] [xtcp.go:179] [fa813de5668759ca] [p2p_rtsp_visitor] open tunnel error: open tunnel timeout.

我目前是这个情况。好像不太行。

@ppl56 commented on GitHub (Oct 12, 2023): 2023/10/12 11:12:11 [W] [xtcp.go:280] [fa813de5668759ca] [p2p_rtsp_visitor] nathole prepare error: discover error: wait response from stun server timeout 2023/10/12 11:12:19 [I] [xtcp.go:283] [fa813de5668759ca] [p2p_rtsp_visitor] nathole prepare success, nat type: HardNAT, behavior: BehaviorPortChanged, addresses: [117.136.80.60:41398 117.136.80.60:17892], assistedAddresses: [192.168.1.12:61937 192.168.205.1:61937 192.168.214.1:61937 192.168.43.80:61937] 2023/10/12 11:12:21 [I] [xtcp.go:309] [fa813de5668759ca] [p2p_rtsp_visitor] get natHoleRespMsg, sid [1697080337c48449f9aff74430], protocol [quic], candidate address [223.104.242.185:7146 223.104.242.185:22356], assisted address [192.168.1.111:54979 10.0.43.205:54979 192.168.0.1:54979 192.168.184.1:54979 192.168.1.105:54979], detectBehavior: {Role:receiver Mode:1 TTL:7 SendDelayMs:0 ReadTimeoutMs:5000 CandidatePorts:[{From:22346 To:22366}] SendRandomPorts:0 ListenRandomPorts:0} 2023/10/12 11:12:21 [W] [xtcp.go:316] [fa813de5668759ca] [p2p_rtsp_visitor] make hole error: wait detect message error: read udp4 0.0.0.0:61937: wsarecvfrom: The connection has been broken due to keep-alive activity detecting a failure while the operation was in progress. 2023/10/12 11:12:26 [E] [xtcp.go:179] [fa813de5668759ca] [p2p_rtsp_visitor] open tunnel error: open tunnel timeout. 我目前是这个情况。好像不太行。

Rows
Columns

[GH-ISSUE #3457] xtcp建立了连接，但好像连接又不成功 #2765

Bug Description

frpc Version

frps Version

System Architecture

Configurations

Logs

Steps to reproduce

Affected area