[GH-ISSUE #4657] 域名换了ip后web正常，手机访问不行 #3680

New issue

Closed

opened 2026-05-05 14:21:40 -06:00 by gitea-mirror · 3 comments

gitea-mirror commented

2026-05-05 14:21:40 -06:00

Owner

Originally created by @liaocheng1 on GitHub (Feb 5, 2025).
Original GitHub issue: https://github.com/fatedier/frp/issues/4657

Bug Description

我有两个外网服务器，之前frps在A上域名指向A的ip，后来换成了B，之后同样的连接用web能正常访问，用手机打开就不能访问，换成A后web和手机都可以开打。git可以访问，clone就不行

frpc Version

0.61.1

frps Version

0.61.1

System Architecture

linux/amd64

Configurations

#frps服务监听的本机端口
bindPort = 7000
vhostHTTPPort = 80
vhostHTTPSPort = 443

#frpc服务监听的本机端口
serverAddr = "x.x.x.x"
serverPort = 7000
proxies
name = "nginx-80"
type = "http"
localIP = "127.0.0.1"
localPort = 80
#remotePort = 80
customDomains = ["xxx"]
proxies
name = "nginx-443"
type = "https"
localIP = "127.0.0.1"
localPort = 443
#remotePort = 443
customDomains = ["xxx"]

Logs

正常web访问的frpc日志
2025/02/05 12:00:40 [D] [proxy_wrapper.go:260] [6cad457551cacc7a] [nginx-443] start a new work connection, localAddr: x.x.x.x:33714 remoteAddr: x.x.x.x:7000
2025/02/05 12:00:40 [T] [proxy.go:144] [6cad457551cacc7a] [nginx-443] handle tcp work connection, useEncryption: false, useCompression: false
2025/02/05 12:00:40 [D] [proxy.go:208] [6cad457551cacc7a] [nginx-443] join connections, localConn(l[127.0.0.1:34320] r[127.0.0.1:443]) workConn(l[192.168.112.162:33714] r[x.x.x.x:7000])
2025/02/05 12:00:46 [D] [control.go:243] [6cad457551cacc7a] send heartbeat to server

异常frpc日志;
2025/02/05 12:53:55 [D] [proxy_wrapper.go:260] [6cad457551cacc7a] [nginx-443] start a new work connection, localAddr: 192.168.112.162:33714 remoteAddr: x.x.x.x:7000
2025/02/05 12:53:55 [T] [proxy.go:144] [6cad457551cacc7a] [nginx-443] handle tcp work connection, useEncryption: false, useCompression: false
2025/02/05 12:53:55 [D] [proxy.go:208] [6cad457551cacc7a] [nginx-443] join connections, localConn(l[127.0.0.1:43150] r[127.0.0.1:443]) workConn(l[192.168.112.162:33714] r[x.x.x.x:7000])
2025/02/05 12:53:55 [D] [proxy.go:220] [6cad457551cacc7a] [nginx-443] join connections closed
2025/02/05 12:53:55 [T] [proxy.go:222] [6cad457551cacc7a] [nginx-443] join connections errors: [read tcp 127.0.0.1:43150->127.0.0.1:443: use of closed network connection]

Steps to reproduce

将域名由指向IP改成B的ip
frpc配置serverAddr改成B的ip
启动frp
4.web用域名正常访问私有git仓库正常
5.git拉取代码异常

Affected area

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

Originally created by @liaocheng1 on GitHub (Feb 5, 2025). Original GitHub issue: https://github.com/fatedier/frp/issues/4657 ### Bug Description 我有两个外网服务器，之前frps在A上域名指向A的ip，后来换成了B，之后同样的连接用web能正常访问，用手机打开就不能访问，换成A后web和手机都可以开打。git可以访问，clone就不行 ### frpc Version 0.61.1 ### frps Version 0.61.1 ### System Architecture linux/amd64 ### Configurations #frps服务监听的本机端口 bindPort = 7000 vhostHTTPPort = 80 vhostHTTPSPort = 443 #frpc服务监听的本机端口 serverAddr = "x.x.x.x" serverPort = 7000 [[proxies]] name = "nginx-80" type = "http" localIP = "127.0.0.1" localPort = 80 #remotePort = 80 customDomains = ["xxx"] [[proxies]] name = "nginx-443" type = "https" localIP = "127.0.0.1" localPort = 443 #remotePort = 443 customDomains = ["xxx"] ### Logs 正常web访问的frpc日志 2025/02/05 12:00:40 [D] [proxy_wrapper.go:260] [6cad457551cacc7a] [nginx-443] start a new work connection, localAddr: x.x.x.x:33714 remoteAddr: x.x.x.x:7000 2025/02/05 12:00:40 [T] [proxy.go:144] [6cad457551cacc7a] [nginx-443] handle tcp work connection, useEncryption: false, useCompression: false 2025/02/05 12:00:40 [D] [proxy.go:208] [6cad457551cacc7a] [nginx-443] join connections, localConn(l[127.0.0.1:34320] r[127.0.0.1:443]) workConn(l[192.168.112.162:33714] r[x.x.x.x:7000]) 2025/02/05 12:00:46 [D] [control.go:243] [6cad457551cacc7a] send heartbeat to server 异常frpc日志; 2025/02/05 12:53:55 [D] [proxy_wrapper.go:260] [6cad457551cacc7a] [nginx-443] start a new work connection, localAddr: 192.168.112.162:33714 remoteAddr: x.x.x.x:7000 2025/02/05 12:53:55 [T] [proxy.go:144] [6cad457551cacc7a] [nginx-443] handle tcp work connection, useEncryption: false, useCompression: false 2025/02/05 12:53:55 [D] [proxy.go:208] [6cad457551cacc7a] [nginx-443] join connections, localConn(l[127.0.0.1:43150] r[127.0.0.1:443]) workConn(l[192.168.112.162:33714] r[x.x.x.x:7000]) 2025/02/05 12:53:55 [D] [proxy.go:220] [6cad457551cacc7a] [nginx-443] join connections closed 2025/02/05 12:53:55 [T] [proxy.go:222] [6cad457551cacc7a] [nginx-443] join connections errors: [read tcp 127.0.0.1:43150->127.0.0.1:443: use of closed network connection] ### Steps to reproduce 1. 将域名由指向IP改成B的ip 2. frpc配置serverAddr改成B的ip 3. 启动frp 4.web用域名正常访问私有git仓库正常 5.git拉取代码异常 ### 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 14:21:41 -06:00

gitea-mirror commented

2026-05-05 14:21:43 -06:00

Author

Owner

@xqzr commented on GitHub (Feb 5, 2025):

web（浏览器）支持 X25519MLKEM768 一些防火墙，可能无法识别。可以访问

@xqzr commented on GitHub (Feb 5, 2025): web（浏览器）支持 X25519MLKEM768 一些防火墙，可能无法识别。可以访问

gitea-mirror commented

2026-05-05 14:21:44 -06:00

Author

Owner

@fatedier commented on GitHub (Feb 7, 2025):

类似的问题尽量优先自行排查应用层的问题。

@fatedier commented on GitHub (Feb 7, 2025): 类似的问题尽量优先自行排查应用层的问题。

gitea-mirror commented

2026-05-05 14:21:45 -06:00

Author

Owner

@vincent067 commented on GitHub (Mar 23, 2026):

Hi @dgtlmoon 👋

I noticed you mentioned the issue resolved itself after some time. This pattern (connection drops every ~5 minutes) often points to a few common causes:

Most Likely Causes:

Idle timeout on intermediate NAT/firewall 🔥
Many corporate firewalls/NAT gateways drop idle connections after 5 minutes. You can fix this by enabling heartbeats:
```
# frpc.toml
transport.heartbeatTimeout = 90
transport.heartbeatInterval = 30
```
TCP connection tracking timeout
Some Linux distributions have aggressive tcp_keepalive settings. Check:
```
sysctl net.ipv4.tcp_keepalive_time
```
Default is often 7200s (2 hours), but some systems override this.
Proxy/Load Balancer idle timeout
If you're connecting through a cloud LB (AWS ALB, etc.), they often have 60-300s idle timeouts.

Diagnostic Tips:

Could you run frpc with debug logging next time it happens?

frpc -c frpc.toml --log-level debug

Also helpful to know:

Are client and server on the same network or across the internet?
Any corporate firewall/proxy in between?
What does frpc --version show on both ends?

The fact that it resolved itself might indicate a temporary network issue or a firewall rule change. If it happens again, the heartbeat settings should help! 👍

Hope this helps diagnose it if it recurs.

@vincent067 commented on GitHub (Mar 23, 2026): Hi @dgtlmoon 👋 I noticed you mentioned the issue resolved itself after some time. This pattern (connection drops every ~5 minutes) often points to a few common causes: ## Most Likely Causes: 1. **Idle timeout on intermediate NAT/firewall** 🔥 Many corporate firewalls/NAT gateways drop idle connections after 5 minutes. You can fix this by enabling heartbeats: ```toml # frpc.toml transport.heartbeatTimeout = 90 transport.heartbeatInterval = 30 ``` 2. **TCP connection tracking timeout** Some Linux distributions have aggressive tcp_keepalive settings. Check: ```bash sysctl net.ipv4.tcp_keepalive_time ``` Default is often 7200s (2 hours), but some systems override this. 3. **Proxy/Load Balancer idle timeout** If you're connecting through a cloud LB (AWS ALB, etc.), they often have 60-300s idle timeouts. ## Diagnostic Tips: Could you run frpc with debug logging next time it happens? ```bash frpc -c frpc.toml --log-level debug ``` Also helpful to know: - Are client and server on the same network or across the internet? - Any corporate firewall/proxy in between? - What does `frpc --version` show on both ends? The fact that it resolved itself might indicate a temporary network issue or a firewall rule change. If it happens again, the heartbeat settings should help! 👍 Hope this helps diagnose it if it recurs.