[GH-ISSUE #4856] Connection Reset by Peer, with `serverAddr` being a domain name

gitea-mirror commented

2026-05-05 14:26:58 -06:00

Owner

Originally created by @MetronLee on GitHub (Jun 27, 2025).
Original GitHub issue: https://github.com/fatedier/frp/issues/4856

Bug Description

FRP 客户端使用域名作为 `serverAddr` 导致连接重置问题 (Connection Reset by Peer with Domain `serverAddr`)

在使用 FRP v0.59.0 ~ v0.63.0 版本进行内网穿透时，配置客户端（frpc）的 serverAddr 为域名形式时，即使该域名能正确解析到服务器的公网 IP，客户端也无法成功连接，并报错 login to the server failed: read tcp ...: read: connection reset by peer。

然而，如果将客户端 frpc.toml 中的 serverAddr 直接配置为服务器的公网 IP 地址，则连接正常。

排查过程

版本一致: 服务端 (frps) 与客户端 (frpc) 均为 v0.63.0。
DNS 解析检查:
- dig 命令确认域名解析结果正确。
- 确认 DNS 服务商侧无 IPv6 (AAAA) 记录。
- 在客户端 hosts 文件中硬编码域名到公网 IP 后，问题依然存在，表明与 DNS 解析本身无关。
网络可达性检查:
- nc -vz <domain> 7000 命令显示端口可达。
- 服务端 ss -tnlp 确认 frps 正在监听 0.0.0.0:7000。
- 无明显防火墙阻挡。
tcpdump 抓包分析:
- 客户端和服务端 tcpdump 均显示 TCP 三次握手成功完成。
- 客户端在 TCP 连接建立后，向服务端发送了 FRP 协议的握手数据。
- 服务端在收到客户端的 FRP 握手数据后，立即向客户端发送了 RST (重置) 包，主动断开连接。 这意味着问题发生在 FRP 协议的应用层握手阶段。
FRP 日志检查:
- 服务端 frps 配置为 log.level = "debug" 后，日志中没有任何关于客户端连接尝试失败的记录，表明连接拒绝发生在日志系统记录之前，或日志级别不够。
版本回滚
- v0.59.0 ~ v0.63.0 均相同
源代码审查:
- Cursor gpt-4.1 未发现异常。

结论

所有证据表明，FRP v0.59.0 ~ v0.63.0 客户端在 serverAddr 配置为域名形式时，即使域名能正确解析到 IP，其内部处理逻辑也与直接使用 IP 地址存在差异。这种差异导致服务端在收到客户端的应用层握手数据后，立即拒绝连接（发送 RST 包），且未记录详细错误日志。这很可能是 FRP 协议在处理客户端通过域名建立连接时存在某种隐式的主机名校验或兼容性问题。

建议 (Suggestion)

请团队调查 FRP v0.63.0 版本中，客户端使用域名作为 serverAddr 时，FRP 协议握手的具体行为，特别是与服务端校验相关的逻辑。(cursor gpt-4.1 未发现异常。）
考虑是否存在与 SNI (Server Name Indication) 类似的主机名传递和校验机制。
检查是否存在由于域名形式输入导致的应用层协议解析错误，从而触发快速拒绝。

Issue for FRP GitHub Repository

Problem Description

When setting up an FRP system (v0.59.0 ～ v0.63.0), the client (frpc) fails to connect with the error login to the server failed: read tcp ...: read: connection reset by peer if serverAddr in frpc.toml is configured with a domain name.

However, if serverAddr in frpc.toml is changed directly to the server's public IP address, the connection establishes and works correctly.

Troubleshooting Steps

Version Consistency: Both frps and frpc are v0.63.0.
DNS Resolution Check:
- Domain name correctly resolves to the server's public IP via dig.
- No IPv6 (AAAA) records exist for the domain on the DNS provider side.
- Hardcoding the domain to the public IP in the client's hosts file did not resolve the issue, indicating it's not a direct DNS resolution problem.
Network Reachability Check:
- nc -vz <domain> 7000 shows the port is reachable.
- frps is confirmed listening on 0.0.0.0:7000 via ss -tnlp.
- No apparent firewall blocks.
tcpdump Analysis:
- Both client and server tcpdump logs confirm successful TCP three-way handshake.
- After establishing the TCP connection, the client sends FRP protocol handshake data to the server.
- Upon receiving the client's FRP handshake data, the server immediately sends an RST (reset) packet, actively terminating the connection. This indicates the issue lies at the FRP application layer handshake.
FRP Log Check:
- Even with log.level = "debug" enabled on the frps side, no detailed error logs or connection attempt failures were recorded, suggesting the connection rejection happens at a very low level before standard logging.
Version Rollback
- v0.59.0 ~ v0.63.0 are the same.
Cource Code Examination:
- No bug found by Cursor gpt-4.1.

Conclusion

All evidence points to an issue with how the FRP v0.59.0 ~ v0.63.0 client handles serverAddr when it's a domain name, even if the domain resolves correctly to an IP. There appears to be a functional difference in its internal processing compared to using a direct IP. This difference causes the server to immediately reject the connection (by sending an RST packet) upon receiving the client's application layer handshake data, without logging detailed errors. This could be a version-specific bug, or related to some implicit hostname validation or compatibility issue within the FRP protocol when a domain is used for connection initiation.

Suggestion

Please investigate the specific behavior of FRP v0.63.0 when the client uses a domain name for serverAddr, focusing on the FRP protocol handshake and server-side validation logic.
Consider if there's an implicit hostname transmission and validation mechanism, similar to SNI, involved.
Examine if the domain name input form leads to an application-layer protocol parsing error that triggers an immediate rejection.

frpc Version

0.63.0

frps Version

0.63.0

System Architecture

server: linux/amd64, client: macOS/arm64

Configurations

# frps.toml
bindPort = 7000
auth.method = "token"
auth.token = "***"

webServer.addr = "0.0.0.0"
webServer.port = 7500
webServer.user = "admin"
webServer.password = "***"

log.to = "./frps.log"
log.level = "debug"
log.maxDays = 3

# frpc.toml
serverAddr = "my.domain.com"
# serverAddr = "52.77.***.***"
serverPort = 7000
auth.method = "token"
auth.token = "***"

log.to = "./frpc.log"
# trace, debug, info, warn, error
log.level = "debug"
log.maxDays = 3

[[proxies]]
name = "test-tcp"
type = "tcp"
localIP = "127.0.0.1"
localPort = 22
remotePort = 6000

Logs

frpc.log

2025-06-27 22:06:37.838 [I] [sub/root.go:149] start frpc service for config file [frpc.toml]
2025-06-27 22:06:37.838 [I] [client/service.go:314] try to connect to server...
2025-06-27 22:06:38.079 [W] [client/service.go:317] connect to server error: read tcp 172.31.X.X:56323->52.77.X.X:7000: read: connection reset by peer
2025-06-27 22:06:38.079 [I] [sub/root.go:167] frpc service for config file [frpc.toml] stopped

Nothing appeared in frps.log at the same time.

Steps to reproduce

Assign a domain name to serverAddr in frpc.toml

serverAddr = "my.domain.com"

Affected area

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

Originally created by @MetronLee on GitHub (Jun 27, 2025). Original GitHub issue: https://github.com/fatedier/frp/issues/4856 ### Bug Description ## FRP 客户端使用域名作为 `serverAddr` 导致连接重置问题 (Connection Reset by Peer with Domain `serverAddr`) 在使用 FRP `v0.59.0 ~ v0.63.0` 版本进行内网穿透时，配置客户端（`frpc`）的 `serverAddr` 为域名形式时，即使该域名能正确解析到服务器的公网 IP，客户端也无法成功连接，并报错 `login to the server failed: read tcp ...: read: connection reset by peer`。然而，如果将客户端 `frpc.toml` 中的 `serverAddr` 直接配置为服务器的公网 IP 地址，则连接正常。 ### 排查过程 1. **版本一致:** 服务端 (`frps`) 与客户端 (`frpc`) 均为 `v0.63.0`。 2. **DNS 解析检查:** * `dig` 命令确认域名解析结果正确。 * 确认 DNS 服务商侧无 IPv6 (AAAA) 记录。 * 在客户端 `hosts` 文件中硬编码域名到公网 IP 后，问题依然存在，表明与 DNS 解析本身无关。 3. **网络可达性检查:** * `nc -vz <domain> 7000` 命令显示端口可达。 * 服务端 `ss -tnlp` 确认 `frps` 正在监听 `0.0.0.0:7000`。 * 无明显防火墙阻挡。 4. **`tcpdump` 抓包分析:** * **客户端和服务端 `tcpdump` 均显示 TCP 三次握手成功完成。** * **客户端在 TCP 连接建立后，向服务端发送了 FRP 协议的握手数据。** * **服务端在收到客户端的 FRP 握手数据后，立即向客户端发送了 RST (重置) 包，主动断开连接。** 这意味着问题发生在 FRP 协议的应用层握手阶段。 5. **FRP 日志检查:** * 服务端 `frps` 配置为 `log.level = "debug"` 后，日志中没有任何关于客户端连接尝试失败的记录，表明连接拒绝发生在日志系统记录之前，或日志级别不够。 6. **版本回滚** * `v0.59.0 ~ v0.63.0` 均相同 7. **源代码审查:** * Cursor gpt-4.1 未发现异常。 ### 结论所有证据表明，FRP `v0.59.0 ~ v0.63.0` 客户端在 `serverAddr` 配置为域名形式时，即使域名能正确解析到 IP，其内部处理逻辑也与直接使用 IP 地址存在差异。这种差异导致服务端在收到客户端的应用层握手数据后，立即拒绝连接（发送 RST 包），且未记录详细错误日志。这很可能是 FRP 协议在处理客户端通过域名建立连接时存在某种隐式的主机名校验或兼容性问题。 ### 建议 (Suggestion) * 请团队调查 FRP `v0.63.0` 版本中，客户端使用域名作为 `serverAddr` 时，FRP 协议握手的具体行为，特别是与服务端校验相关的逻辑。(cursor gpt-4.1 未发现异常。） * 考虑是否存在与 SNI (Server Name Indication) 类似的主机名传递和校验机制。 * 检查是否存在由于域名形式输入导致的应用层协议解析错误，从而触发快速拒绝。 --- ## Issue for FRP GitHub Repository ### Problem Description When setting up an FRP system (`v0.59.0 ～ v0.63.0`), the client (`frpc`) fails to connect with the error `login to the server failed: read tcp ...: read: connection reset by peer` if `serverAddr` in `frpc.toml` is configured with a domain name. However, if `serverAddr` in `frpc.toml` is changed directly to the server's public IP address, the connection establishes and works correctly. ### Troubleshooting Steps 1. **Version Consistency:** Both `frps` and `frpc` are `v0.63.0`. 2. **DNS Resolution Check:** * Domain name correctly resolves to the server's public IP via `dig`. * No IPv6 (AAAA) records exist for the domain on the DNS provider side. * Hardcoding the domain to the public IP in the client's `hosts` file did not resolve the issue, indicating it's not a direct DNS resolution problem. 3. **Network Reachability Check:** * `nc -vz <domain> 7000` shows the port is reachable. * `frps` is confirmed listening on `0.0.0.0:7000` via `ss -tnlp`. * No apparent firewall blocks. 4. **`tcpdump` Analysis:** * **Both client and server `tcpdump` logs confirm successful TCP three-way handshake.** * **After establishing the TCP connection, the client sends FRP protocol handshake data to the server.** * **Upon receiving the client's FRP handshake data, the server immediately sends an RST (reset) packet, actively terminating the connection.** This indicates the issue lies at the FRP application layer handshake. 5. **FRP Log Check:** * Even with `log.level = "debug"` enabled on the `frps` side, no detailed error logs or connection attempt failures were recorded, suggesting the connection rejection happens at a very low level before standard logging. 6. **Version Rollback** * `v0.59.0 ~ v0.63.0` are the same. 7. **Cource Code Examination:** * No bug found by Cursor gpt-4.1. ### Conclusion All evidence points to an issue with how the FRP `v0.59.0 ~ v0.63.0` client handles `serverAddr` when it's a domain name, even if the domain resolves correctly to an IP. There appears to be a functional difference in its internal processing compared to using a direct IP. This difference causes the server to immediately reject the connection (by sending an RST packet) upon receiving the client's application layer handshake data, without logging detailed errors. This could be a version-specific bug, or related to some implicit hostname validation or compatibility issue within the FRP protocol when a domain is used for connection initiation. ### Suggestion * Please investigate the specific behavior of FRP `v0.63.0` when the client uses a domain name for `serverAddr`, focusing on the FRP protocol handshake and server-side validation logic. * Consider if there's an implicit hostname transmission and validation mechanism, similar to SNI, involved. * Examine if the domain name input form leads to an application-layer protocol parsing error that triggers an immediate rejection. ### frpc Version 0.63.0 ### frps Version 0.63.0 ### System Architecture server: linux/amd64, client: macOS/arm64 ### Configurations ```frps.toml # frps.toml bindPort = 7000 auth.method = "token" auth.token = "***" webServer.addr = "0.0.0.0" webServer.port = 7500 webServer.user = "admin" webServer.password = "***" log.to = "./frps.log" log.level = "debug" log.maxDays = 3 ``` ```frpc.toml # frpc.toml serverAddr = "my.domain.com" # serverAddr = "52.77.***.***" serverPort = 7000 auth.method = "token" auth.token = "***" log.to = "./frpc.log" # trace, debug, info, warn, error log.level = "debug" log.maxDays = 3 [[proxies]] name = "test-tcp" type = "tcp" localIP = "127.0.0.1" localPort = 22 remotePort = 6000 ``` ### Logs `frpc.log` ``` 2025-06-27 22:06:37.838 [I] [sub/root.go:149] start frpc service for config file [frpc.toml] 2025-06-27 22:06:37.838 [I] [client/service.go:314] try to connect to server... 2025-06-27 22:06:38.079 [W] [client/service.go:317] connect to server error: read tcp 172.31.X.X:56323->52.77.X.X:7000: read: connection reset by peer 2025-06-27 22:06:38.079 [I] [sub/root.go:167] frpc service for config file [frpc.toml] stopped ``` Nothing appeared in `frps.log` at the same time. ### Steps to reproduce Assign a domain name to `serverAddr` in `frpc.toml` ``` serverAddr = "my.domain.com" ``` ### Affected area - [ ] Docs - [ ] Installation - [ ] Performance and Scalability - [ ] Security - [x] User Experience - [ ] Test and Release - [ ] Developer Infrastructure - [ ] Client Plugin - [ ] Server Plugin - [ ] Extensions - [ ] Others

gitea-mirror

2026-05-05 14:26:58 -06:00

closed this issue
added the
lifecycle/stale
label

gitea-mirror commented

2026-05-05 14:27:02 -06:00

Author

Owner

@devin-ai-integration[bot] commented on GitHub (Jul 1, 2025):

Investigation Results

After thorough code analysis and testing, this appears to be a network/firewall issue rather than a frp code problem.

Key Findings:

No code-level differences exist between domain and IP handling in frp
Local testing with various domains (localhost, custom domains) all work successfully
The Login message structure and connection logic are identical for both scenarios

Root Cause:
Network firewalls or DPI devices are likely filtering TLS traffic differently when domain names are used in SNI, causing connection resets during handshake.

Solutions:

Workaround: Use IP address instead of domain in serverAddr
Network troubleshooting: Check firewall/DPI settings for SNI filtering
Testing: Try from different networks or with VPN to bypass restrictions

Verification:

# Test TLS handshake directly
openssl s_client -connect your.domain.com:7000 -servername your.domain.com

This is an infrastructure issue, not a frp bug. The consistent local test results confirm the codebase handles domains correctly.

@devin-ai-integration[bot] commented on GitHub (Jul 1, 2025): **Investigation Results** After thorough code analysis and testing, this appears to be a **network/firewall issue** rather than a frp code problem. **Key Findings:** - No code-level differences exist between domain and IP handling in frp - Local testing with various domains (localhost, custom domains) all work successfully - The Login message structure and connection logic are identical for both scenarios **Root Cause:** Network firewalls or DPI devices are likely filtering TLS traffic differently when domain names are used in SNI, causing connection resets during handshake. **Solutions:** 1. **Workaround:** Use IP address instead of domain in `serverAddr` 2. **Network troubleshooting:** Check firewall/DPI settings for SNI filtering 3. **Testing:** Try from different networks or with VPN to bypass restrictions **Verification:** ```bash # Test TLS handshake directly openssl s_client -connect your.domain.com:7000 -servername your.domain.com ``` This is an infrastructure issue, not a frp bug. The consistent local test results confirm the codebase handles domains correctly.

gitea-mirror commented

2026-05-05 14:27:02 -06:00

Author

Owner

@github-actions[bot] commented on GitHub (Jul 16, 2025):

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 (Jul 16, 2025): 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:27:03 -06:00

Author

Owner

@BustedSec commented on GitHub (Jul 16, 2025):

Set to 10.10 rfc 1918 address

Get Outlook for Androidhttps://aka.ms/AAb9ysg

From: github-actions[bot] @.>
Sent: Tuesday, July 15, 2025 5:42:36 PM
To: fatedier/frp @.>
Cc: Subscribed @.***>
Subject: Re: [fatedier/frp] Connection Reset by Peer, with serverAddr being a domain name (Issue #4856)

[https://avatars.githubusercontent.com/in/15368?s=20&v=4]github-actions[bot] left a comment (fatedier/frp#4856)https://github.com/fatedier/frp/issues/4856#issuecomment-3076365046

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

—
Reply to this email directly, view it on GitHubhttps://github.com/fatedier/frp/issues/4856#issuecomment-3076365046, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABYWWB4VS3YI2SBZI4VKI5D3IWNXZAVCNFSM6AAAAACAJDOVCWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTANZWGM3DKMBUGY.
You are receiving this because you are subscribed to this thread.Message ID: @.***>

@BustedSec commented on GitHub (Jul 16, 2025): Set to 10.10 rfc 1918 address Get Outlook for Android<https://aka.ms/AAb9ysg> ________________________________ From: github-actions[bot] ***@***.***> Sent: Tuesday, July 15, 2025 5:42:36 PM To: fatedier/frp ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [fatedier/frp] Connection Reset by Peer, with `serverAddr` being a domain name (Issue #4856) [https://avatars.githubusercontent.com/in/15368?s=20&v=4]github-actions[bot] left a comment (fatedier/frp#4856)<https://github.com/fatedier/frp/issues/4856#issuecomment-3076365046> Issues go stale after 14d of inactivity. Stale issues rot after an additional 3d of inactivity and eventually close. — Reply to this email directly, view it on GitHub<https://github.com/fatedier/frp/issues/4856#issuecomment-3076365046>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABYWWB4VS3YI2SBZI4VKI5D3IWNXZAVCNFSM6AAAAACAJDOVCWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTANZWGM3DKMBUGY>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

gitea-mirror commented

2026-05-05 14:27:03 -06:00

Author

Owner

@ly360 commented on GitHub (Jul 29, 2025):

境内服务器且域名没备案吧？

@ly360 commented on GitHub (Jul 29, 2025): 境内服务器且域名没备案吧？

gitea-mirror commented

2026-05-05 14:27:04 -06:00

Author

Owner

@MetronLee commented on GitHub (Jul 30, 2025):

境内服务器且域名没备案吧？

AWS EC2 服务器，namesilo的域名，在新加坡使用

@MetronLee commented on GitHub (Jul 30, 2025): > 境内服务器且域名没备案吧？ AWS EC2 服务器，namesilo的域名，在新加坡使用

gitea-mirror commented

2026-05-05 14:27:04 -06:00

Author

Owner

@DaPoHou commented on GitHub (Aug 5, 2025):

是的，就这两天我也突然遇到这个问题，一直运行好好的，突然出现这个问题。使用的版本是0.51.3，是通过同一城市不同运营商之间互联。通过server_addr配置域名无法连接，换成ip地址就好了。我反而怀疑是不是运营商搞得鬼。
############
经过我进一步排查，发现我使用的域名在国内部分dns上被解析到了反诈ip上，不知道是不是这个原因。

@DaPoHou commented on GitHub (Aug 5, 2025): 是的，就这两天我也突然遇到这个问题，一直运行好好的，突然出现这个问题。使用的版本是0.51.3，是通过同一城市不同运营商之间互联。通过server_addr配置域名无法连接，换成ip地址就好了。我反而怀疑是不是运营商搞得鬼。 ############ 经过我进一步排查，发现我使用的域名在国内部分dns上被解析到了反诈ip上，不知道是不是这个原因。

gitea-mirror commented

2026-05-05 14:27:05 -06:00

Author

Owner

@github-actions[bot] commented on GitHub (Aug 20, 2025):

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 (Aug 20, 2025): 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:27:05 -06:00

Author

Owner

@MetronLee commented on GitHub (Aug 24, 2025):

是的，就这两天我也突然遇到这个问题，一直运行好好的，突然出现这个问题。使用的版本是0.51.3，是通过同一城市不同运营商之间互联。通过server_addr配置域名无法连接，换成ip地址就好了。我反而怀疑是不是运营商搞得鬼。 ############ 经过我进一步排查，发现我使用的域名在国内部分dns上被解析到了反诈ip上，不知道是不是这个原因。

应该不是，我在境外用的境外的dns

@MetronLee commented on GitHub (Aug 24, 2025): > 是的，就这两天我也突然遇到这个问题，一直运行好好的，突然出现这个问题。使用的版本是0.51.3，是通过同一城市不同运营商之间互联。通过server_addr配置域名无法连接，换成ip地址就好了。我反而怀疑是不是运营商搞得鬼。 ############ 经过我进一步排查，发现我使用的域名在国内部分dns上被解析到了反诈ip上，不知道是不是这个原因。应该不是，我在境外用的境外的dns

Rows
Columns

[GH-ISSUE #4856] Connection Reset by Peer, with serverAddr being a domain name #3831

Bug Description

FRP 客户端使用域名作为 serverAddr 导致连接重置问题 (Connection Reset by Peer with Domain serverAddr)

排查过程

结论

建议 (Suggestion)

Issue for FRP GitHub Repository

Problem Description

Troubleshooting Steps

Conclusion

Suggestion

frpc Version

frps Version

System Architecture

Configurations

Logs

Steps to reproduce

Affected area

[GH-ISSUE #4856] Connection Reset by Peer, with `serverAddr` being a domain name #3831

FRP 客户端使用域名作为 `serverAddr` 导致连接重置问题 (Connection Reset by Peer with Domain `serverAddr`)