[GH-ISSUE #5172] [Bug] xtcp 延迟连接本地服务，导致 VNC(RFB) 这类 server-first 协议无法成功建立连接。

gitea-mirror commented

2026-05-05 14:33:50 -06:00

Owner

Copy link

Originally created by @fondoger on GitHub (Feb 10, 2026).
Original GitHub issue: https://github.com/fatedier/frp/issues/5172

Bug Description

问题描述

在 xtcp 模式下，服务端侧 frpc（提供 local port 转发的一侧）似乎采用了 “收到对端首个应用层数据后才去连接本地服务”的 lazy dial 行为。
这会导致server-first 协议（例如 VNC/RFB：服务端先发版本 banner）产生死锁：客户端等待服务端 banner，但 frp 未连接到本地 VNC server，因此 banner 永远不会产生，表现为 VNC Viewer 一直卡在 “Connecting”。

复现步骤 / Steps to Reproduce

在 A 上开启 VNC server，监听 5900（macOS 自带屏幕共享/VNC）。
A、B 均运行 frpc，用 xtcp 将 B:5900 转发到 A:5900
在 B 上用 VNC Viewer 连接 127.0.0.1:5900
观察：VNC Viewer 长时间停留在 “Connecting”，无明确报错。

期望行为

建立 xtcp 连接后，A 侧 frpc 应立即 dial 本地 127.0.0.1:5900，从而让 VNC server 发送首包 RFB banner（例如 RFB 003.889\n），并转发给 B，连接正常完成。

实际行为

A 侧 frpc 只有在收到来自 B 的首个应用层数据后 才会开始连接本地 5900。
但 VNC/RFB 规定是 server 先发 banner，客户端（VNC Viewer）在收到 banner 前不会主动发送应用层数据 → 双方互相等待，连接卡住。

影响范围

不仅 VNC，任何 server-first 协议都可能受影响（例如 SMTP greeting、某些 banner-based 服务等）。

建议修复方向 / Possible Fix

在 xtcp 的新连接建立后（会话/stream 建立时），立即连接 local service，而不是等到收到首个 payload 再连接；或提供一个可配置开关（e.g. lazy_dial=false）。

其他信息

确定能打洞成功。且通过xtcp转发ssh 22端口完全正常使用。
使用非xtcp协议，直接采用服务器中转流量暴露5900端口到公网ip时，也能正常连接 VNC 服务。

frpc Version

latest

frps Version

latest

System Architecture

macos/linux

Configurations

N/A

Logs

No response

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 @fondoger on GitHub (Feb 10, 2026). Original GitHub issue: https://github.com/fatedier/frp/issues/5172 ### Bug Description ## 问题描述在 `xtcp` 模式下，服务端侧 `frpc`（提供 local port 转发的一侧）似乎采用了 **“收到对端首个应用层数据后才去连接本地服务”的 lazy dial** 行为。这会导致**server-first 协议**（例如 VNC/RFB：服务端先发版本 banner）产生死锁：客户端等待服务端 banner，但 frp 未连接到本地 VNC server，因此 banner 永远不会产生，表现为 VNC Viewer 一直卡在 “Connecting”。 ## 复现步骤 / Steps to Reproduce 1. 在 A 上开启 VNC server，监听 `5900`（macOS 自带屏幕共享/VNC）。 2. A、B 均运行 `frpc`，用 `xtcp` 将 `B:5900` 转发到 `A:5900` 3. 在 B 上用 VNC Viewer 连接 `127.0.0.1:5900` 4. 观察：VNC Viewer 长时间停留在 “Connecting”，无明确报错。 ## 期望行为建立 xtcp 连接后，A 侧 frpc **应立即 dial 本地 `127.0.0.1:5900`**，从而让 VNC server 发送首包 RFB banner（例如 `RFB 003.889\n`），并转发给 B，连接正常完成。 ## 实际行为 A 侧 frpc **只有在收到来自 B 的首个应用层数据后** 才会开始连接本地 `5900`。但 VNC/RFB 规定是 **server 先发 banner**，客户端（VNC Viewer）在收到 banner 前不会主动发送应用层数据 → 双方互相等待，连接卡住。 ## 影响范围不仅 VNC，任何 **server-first** 协议都可能受影响（例如 SMTP greeting、某些 banner-based 服务等）。 ## 建议修复方向 / Possible Fix 在 xtcp 的新连接建立后（会话/stream 建立时），**立即连接 local service**，而不是等到收到首个 payload 再连接；或提供一个可配置开关（e.g. `lazy_dial=false`）。 ## 其他信息 1. 确定能打洞成功。且通过xtcp转发ssh 22端口完全正常使用。 2. 使用非xtcp协议，直接采用服务器中转流量暴露5900端口到公网ip时，也能正常连接 VNC 服务。 ### frpc Version latest ### frps Version latest ### System Architecture macos/linux ### Configurations N/A ### Logs _No response_ ### 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

2026-05-05 14:33:50 -06:00

closed this issue
added the
lifecycle/stale
label

gitea-mirror commented

2026-05-05 14:33:53 -06:00

Author

Owner

Copy link

@fondoger commented on GitHub (Feb 10, 2026):

搜索到两个VNC相关issue，应该都是同一个原因导致的。
https://github.com/fatedier/frp/issues/4491
https://github.com/fatedier/frp/issues/1221

@fondoger commented on GitHub (Feb 10, 2026): 搜索到两个VNC相关issue，应该都是同一个原因导致的。 https://github.com/fatedier/frp/issues/4491 https://github.com/fatedier/frp/issues/1221

gitea-mirror commented

2026-05-05 14:33:54 -06:00

Author

Owner

Copy link

@github-actions[bot] commented on GitHub (Feb 25, 2026):

Issues go stale after 14d of inactivity. Stale issues rot after an additional 3d of inactivity and eventually close.

@github-actions[bot] commented on GitHub (Feb 25, 2026): Issues go stale after 14d of inactivity. Stale issues rot after an additional 3d of inactivity and eventually close.

gitea-mirror commented

2026-05-05 14:33:54 -06:00

Author

Owner

Copy link

@fondoger commented on GitHub (Feb 25, 2026):

this is not a stale issue.

@fondoger commented on GitHub (Feb 25, 2026): this is not a stale issue.

gitea-mirror commented

2026-05-05 14:33:55 -06:00

Author

Owner

Copy link

@github-actions[bot] commented on GitHub (Mar 13, 2026):

Issues go stale after 14d of inactivity. Stale issues rot after an additional 3d of inactivity and eventually close.

@github-actions[bot] commented on GitHub (Mar 13, 2026): Issues go stale after 14d of inactivity. Stale issues rot after an additional 3d of inactivity and eventually close.

gitea-mirror commented

2026-05-05 14:33:55 -06:00

Author

Owner

Copy link

@fondoger commented on GitHub (Mar 13, 2026):

this is not a stale issue.

@fondoger commented on GitHub (Mar 13, 2026): this is not a stale issue.

gitea-mirror commented

2026-05-05 14:33:55 -06:00

Author

Owner

Copy link

@github-actions[bot] commented on GitHub (Mar 28, 2026):

Issues go stale after 14d of inactivity. Stale issues rot after an additional 3d of inactivity and eventually close.

@github-actions[bot] commented on GitHub (Mar 28, 2026): Issues go stale after 14d of inactivity. Stale issues rot after an additional 3d of inactivity and eventually close.

No Branch/Tag specified