github-starred/frp

Fork 0

mirror of https://github.com/fatedier/frp.git synced 2026-05-15 08:05:49 -06:00

[GH-ISSUE #1452] Support network condition changes (DDNS) #1144

New issue

Closed

opened 2026-05-05 12:44:03 -06:00 by gitea-mirror · 3 comments

gitea-mirror commented

2026-05-05 12:44:03 -06:00

Owner

Originally created by @loblab on GitHub (Oct 2, 2019).
Original GitHub issue: https://github.com/fatedier/frp/issues/1452

What version of frp are you using (./frpc -v or ./frps -v)?
0.29

What operating system and processor architecture are you using (go env)?
docker 18.06.1-ce go1.10.3 ubuntn 18.04, host: ubuntu 18.04 or 16.04
(docker is not the important factor)

Configures you used:
Simple as examples.
Use domain name (not IP). DDNS

Steps to reproduce the issue:

Case 1:

Set the client frpc as auto startup
Reboot the client OS
Cannot connect server

2019/10/02 09:37:20 [W] [service.go:86] login to server failed: dial tcp: lookup my.domain.com on [::1]:53: read udp [::1]:48917->[::1]:53: read: connection refused
2019/10/02 09:37:30 [W] [service.go:86] login to server failed: dial tcp: lookup my.domain.com on [::1]:53: read udp [::1]:50790->[::1]:53: read: connection refused
...

If I restart the client, it will succeed to connect.

Case 2:

Reboot server side router (the IP address will change, and I am using dynamic DNS).

2019/10/02 09:45:01 [I] [control.go:237] control writer is closing
2019/10/02 09:45:01 [E] [control.go:136] work connection closed, EOF
2019/10/02 09:45:01 [I] [service.go:137] try to reconnect to server...
2019/10/02 09:47:11 [W] [service.go:140] reconnect to server error: dial tcp my.old.ip.address:port: connect: connection timed out
2019/10/02 09:47:12 [I] [service.go:137] try to reconnect to server...
2019/10/02 09:49:28 [W] [service.go:140] reconnect to server error: dial tcp my.old.ip.address:port: connect: connection timed out
2019/10/02 09:49:30 [I] [service.go:137] try to reconnect to server...
...

Describe the results you received:

When network changes, or not ready, connection retrials always fail even the network becomes ready soon.

Describe the results you expected:

Work as the network ready

Additional information you deem important (e.g. issue happens only occasionally):

Always

Can you point out what caused this issue (optional)

Case 1. network not ready as the client reboot, but will ready soon. seems frpc does not resolve the DNS, or using the old resolve results.
Case 2. DNS changes as server router reboot, but will ready soon. frpc still retry on old IP.

Case 1: 客户端操作系统重启时，frpc开机自启动，但网络部分可能没有完全ready（比如DNS）。frpc一直重试失败。但实际上，比如1分钟后，网络就ready了。此时只有手动重启frpc才行。这导致客户端机器重启后不能自动连接。

Case 2: 服务器端路由器重启后，IP地址改变。但我使用的是动态域名，一两分钟后就会正常。但此时客户端一直检测的是与旧的IP地址的连接（我的配置文件里使用的是域名）。所以重试永远不会成功。

Case 3: 服务器端机器重启，未测试。

总而言之，我希望在服务器端或客户端任何重启、或网络状态变化时，对理论上能恢复的情况，都能自动恢复连接。自动、自动、自动！很重要。

frp简单易用。谢谢国人又做了这么好的一款开源软件！

Originally created by @loblab on GitHub (Oct 2, 2019). Original GitHub issue: https://github.com/fatedier/frp/issues/1452 **What version of frp are you using (./frpc -v or ./frps -v)?** 0.29 **What operating system and processor architecture are you using (`go env`)?** docker 18.06.1-ce go1.10.3 ubuntn 18.04, host: ubuntu 18.04 or 16.04 (docker is not the important factor) **Configures you used:** Simple as examples. Use domain name (not IP). DDNS **Steps to reproduce the issue:** Case 1: 1. Set the client frpc as auto startup 2. Reboot the client OS 3. Cannot connect server ``` 2019/10/02 09:37:20 [W] [service.go:86] login to server failed: dial tcp: lookup my.domain.com on [::1]:53: read udp [::1]:48917->[::1]:53: read: connection refused 2019/10/02 09:37:30 [W] [service.go:86] login to server failed: dial tcp: lookup my.domain.com on [::1]:53: read udp [::1]:50790->[::1]:53: read: connection refused ... ``` If I restart the client, it will succeed to connect. Case 2: Reboot server side router (the IP address will change, and I am using dynamic DNS). ``` 2019/10/02 09:45:01 [I] [control.go:237] control writer is closing 2019/10/02 09:45:01 [E] [control.go:136] work connection closed, EOF 2019/10/02 09:45:01 [I] [service.go:137] try to reconnect to server... 2019/10/02 09:47:11 [W] [service.go:140] reconnect to server error: dial tcp my.old.ip.address:port: connect: connection timed out 2019/10/02 09:47:12 [I] [service.go:137] try to reconnect to server... 2019/10/02 09:49:28 [W] [service.go:140] reconnect to server error: dial tcp my.old.ip.address:port: connect: connection timed out 2019/10/02 09:49:30 [I] [service.go:137] try to reconnect to server... ... ``` **Describe the results you received:** When network changes, or not ready, connection retrials always fail even the network becomes ready soon. **Describe the results you expected:** Work as the network ready **Additional information you deem important (e.g. issue happens only occasionally):** Always **Can you point out what caused this issue (optional)** Case 1. network not ready as the client reboot, but will ready soon. seems frpc does not resolve the DNS, or using the old resolve results. Case 2. DNS changes as server router reboot, but will ready soon. frpc still retry on old IP. Case 1: 客户端操作系统重启时，frpc开机自启动，但网络部分可能没有完全ready（比如DNS）。frpc一直重试失败。但实际上，比如1分钟后，网络就ready了。此时只有手动重启frpc才行。这导致客户端机器重启后不能自动连接。 Case 2: 服务器端路由器重启后，IP地址改变。但我使用的是动态域名，一两分钟后就会正常。但此时客户端一直检测的是与旧的IP地址的连接（我的配置文件里使用的是域名）。所以重试永远不会成功。 Case 3: 服务器端机器重启，未测试。总而言之，我希望在服务器端或客户端任何重启、或网络状态变化时，对理论上能恢复的情况，都能自动恢复连接。自动、自动、自动！很重要。 frp简单易用。谢谢国人又做了这么好的一款开源软件！

gitea-mirror closed this issue

2026-05-05 12:44:04 -06:00

gitea-mirror commented

2026-05-05 12:44:06 -06:00

Author

Owner

@loblab commented on GitHub (Oct 2, 2019):

A workaround is to use restart:always in docker.

忘了说了，我用docker的restart always也可以解决这个问题，只要frpc连不上就退出就行了。貌似 login_fail_exit = true 是控制这个的（不仅登录不上退出，任何导致连接不上的都退出）。

所以，这个特性对于使用docker的场景，不是很急迫了。

@loblab commented on GitHub (Oct 2, 2019): A workaround is to use restart:always in docker. 忘了说了，我用docker的restart always也可以解决这个问题，只要frpc连不上就退出就行了。貌似 login_fail_exit = true 是控制这个的（不仅登录不上退出，任何导致连接不上的都退出）。所以，这个特性对于使用docker的场景，不是很急迫了。

gitea-mirror commented

2026-05-05 12:44:07 -06:00

Author

Owner

@fatedier commented on GitHub (Oct 5, 2019):

Systemd can control the start order. Let frp start after the network is ready.
I'm not sure what caused the problem, i test success. Maybe it is releated about the os DNS cache ?

@fatedier commented on GitHub (Oct 5, 2019): 1. Systemd can control the start order. Let frp start after the network is ready. 2. I'm not sure what caused the problem, i test success. Maybe it is releated about the os DNS cache ?

gitea-mirror commented

2026-05-05 12:44:08 -06:00

Author

Owner

@loblab commented on GitHub (Oct 6, 2019):

@fatedier
Thanks. Yes, systemd can work well with Restart=on-failure.
I set login_fail_exit = false at first time.
If I set login_fail_exit = true, and use "restart on failure" (in systemd or docker), it is not a problem any more.
Thank you for the great software!

@loblab commented on GitHub (Oct 6, 2019): @fatedier Thanks. Yes, systemd can work well with Restart=on-failure. I set login_fail_exit = false at first time. If I set login_fail_exit = true, and use "restart on failure" (in systemd or docker), it is not a problem any more. Thank you for the great software!