github-starred/frp
2
0
Fork 0
mirror of https://github.com/fatedier/frp.git synced 2026-05-15 08:05:49 -06:00
Code Issues 40 Projects Packages Wiki Activity Actions 1

[GH-ISSUE #1508] Connection closed unexpectedly and stuck in a disconnect-reconnect loop #1191

New issue
Closed
opened 2026-05-05 12:46:02 -06:00 by gitea-mirror · 10 comments
gitea-mirror commented 2026-05-05 12:46:02 -06:00
Owner
Copy link

Originally created by @nakululusatuva on GitHub (Nov 10, 2019).
Original GitHub issue: https://github.com/fatedier/frp/issues/1508

Issue is only used for submitting bug report and documents typo. If there are same issues or answers can be found in documents, we will close it directly.
(为了节约时间，提高处理问题的效率，不按照格式填写的 issue 将会直接关闭。)
(请不要在 issue 评论中出现无意义的 加1，我也是 等内容，将会被直接删除。)
(由于个人精力有限，和系统环境，网络环境等相关的求助问题请转至其他论坛或社交平台。)

Use the commands below to provide key information from your environment:
You do NOT have to include this information if this is a FEATURE REQUEST

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

What operating system and processor architecture are you using (go env)?
frps: Debian 4.19.67-2+deb10u1 (2019-09-20) x86_64
frpc: Debian 4.19.67-2+deb10u1 (2019-09-20) x86_64

Configures you used:
frps.ini

[common]
bind_port = 7000
bind_udp_port = 7001
token = ********
dashboard_addr = 0.0.0.0
dashboard_port = 16666
dashboard_user = ****
dashboard_pwd = ********

frpc.ini

[common]
server_addr = x.x.x.x
server_port = 7000
token = ********


[ssh]
type = tcp
local_ip = 127.0.0.1
local_port = 22
remote_port = 2222
use_encryption = true
use_compression = true

[bitcoin]
type = tcp
local_ip = 127.0.0.1
local_port = 8333
remote_port = 8333
use_encryption = true
use_compression = true

Steps to reproduce the issue:

  1. At first, it performs well and everything is working properly then the connection was unexpectedly closed.
  2. Then a loop of reconnecting happened, the client tries to reconnect every 30 seconds.
  3. Sometimes it backs to normal after a while but sometimes I have to restart both the server and client to solve it.

Describe the results you received:
Unreliable connections between server-side and client-side

Describe the results you expected:
More stability and no more disconnect-reconnect loop.

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

Nov 10 23:36:42 Laptop frpc[1432]: 2019/11/10 23:36:42 [I] [service.go:221] login to server success, get run id [45a96bbb1c09c5a3], server udp port [7001]
Nov 10 23:36:42 Laptop frpc[1432]: 2019/11/10 23:36:42 [I] [proxy_manager.go:137] [45a96bbb1c09c5a3] proxy added: [ssh]
Nov 10 23:37:12 Laptop frpc[1432]: 2019/11/10 23:37:12 [E] [control.go:127] work connection closed, EOF
Nov 10 23:37:12 Laptop frpc[1432]: 2019/11/10 23:37:12 [I] [control.go:228] control writer is closing
Nov 10 23:37:12 Laptop frpc[1432]: 2019/11/10 23:37:12 [I] [service.go:127] try to reconnect to server...
Nov 10 23:37:15 Laptop frpc[1432]: 2019/11/10 23:37:15 [I] [service.go:221] login to server success, get run id [45a96bbb1c09c5a3], server udp port [7001]
Nov 10 23:37:15 Laptop frpc[1432]: 2019/11/10 23:37:15 [I] [proxy_manager.go:137] [45a96bbb1c09c5a3] proxy added: [ssh]
Nov 10 23:37:43 Laptop frpc[1432]: 2019/11/10 23:37:43 [I] [control.go:228] control writer is closing
Nov 10 23:37:43 Laptop frpc[1432]: 2019/11/10 23:37:43 [E] [control.go:127] work connection closed, EOF
Nov 10 23:37:43 Laptop frpc[1432]: 2019/11/10 23:37:43 [I] [service.go:127] try to reconnect to server...

Can you point out what caused this issue (optional)

Originally created by @nakululusatuva on GitHub (Nov 10, 2019). Original GitHub issue: https://github.com/fatedier/frp/issues/1508 Issue is only used for submitting bug report and documents typo. If there are same issues or answers can be found in documents, we will close it directly. (为了节约时间，提高处理问题的效率，不按照格式填写的 issue 将会直接关闭。) (请不要在 issue 评论中出现无意义的 **加1**，**我也是** 等内容，将会被直接删除。) (由于个人精力有限，和系统环境，网络环境等相关的求助问题请转至其他论坛或社交平台。) Use the commands below to provide key information from your environment: You do NOT have to include this information if this is a FEATURE REQUEST **What version of frp are you using (./frpc -v or ./frps -v)?** frps: 0.29.0 frpc: 0.27.1 **What operating system and processor architecture are you using (`go env`)?** frps: Debian 4.19.67-2+deb10u1 (2019-09-20) x86_64 frpc: Debian 4.19.67-2+deb10u1 (2019-09-20) x86_64 **Configures you used:** frps.ini ``` [common] bind_port = 7000 bind_udp_port = 7001 token = ******** dashboard_addr = 0.0.0.0 dashboard_port = 16666 dashboard_user = **** dashboard_pwd = ******** ``` frpc.ini ``` [common] server_addr = x.x.x.x server_port = 7000 token = ******** [ssh] type = tcp local_ip = 127.0.0.1 local_port = 22 remote_port = 2222 use_encryption = true use_compression = true [bitcoin] type = tcp local_ip = 127.0.0.1 local_port = 8333 remote_port = 8333 use_encryption = true use_compression = true ``` **Steps to reproduce the issue:** 1. At first, it performs well and everything is working properly then the connection was unexpectedly closed. 2. Then a loop of reconnecting happened, the client tries to reconnect every 30 seconds. 3. Sometimes it backs to normal after a while but sometimes I have to restart both the server and client to solve it. **Describe the results you received:** Unreliable connections between server-side and client-side **Describe the results you expected:** More stability and no more disconnect-reconnect loop. **Additional information you deem important (e.g. issue happens only occasionally):** Logs of client ``` Nov 10 23:36:42 Laptop frpc[1432]: 2019/11/10 23:36:42 [I] [service.go:221] login to server success, get run id [45a96bbb1c09c5a3], server udp port [7001] Nov 10 23:36:42 Laptop frpc[1432]: 2019/11/10 23:36:42 [I] [proxy_manager.go:137] [45a96bbb1c09c5a3] proxy added: [ssh] Nov 10 23:37:12 Laptop frpc[1432]: 2019/11/10 23:37:12 [E] [control.go:127] work connection closed, EOF Nov 10 23:37:12 Laptop frpc[1432]: 2019/11/10 23:37:12 [I] [control.go:228] control writer is closing Nov 10 23:37:12 Laptop frpc[1432]: 2019/11/10 23:37:12 [I] [service.go:127] try to reconnect to server... Nov 10 23:37:15 Laptop frpc[1432]: 2019/11/10 23:37:15 [I] [service.go:221] login to server success, get run id [45a96bbb1c09c5a3], server udp port [7001] Nov 10 23:37:15 Laptop frpc[1432]: 2019/11/10 23:37:15 [I] [proxy_manager.go:137] [45a96bbb1c09c5a3] proxy added: [ssh] Nov 10 23:37:43 Laptop frpc[1432]: 2019/11/10 23:37:43 [I] [control.go:228] control writer is closing Nov 10 23:37:43 Laptop frpc[1432]: 2019/11/10 23:37:43 [E] [control.go:127] work connection closed, EOF Nov 10 23:37:43 Laptop frpc[1432]: 2019/11/10 23:37:43 [I] [service.go:127] try to reconnect to server... ``` **Can you point out what caused this issue (optional)**
gitea-mirror commented 2026-05-05 12:46:04 -06:00
Author
Owner
Copy link

@fatedier commented on GitHub (Nov 11, 2019):

Any log of frps?

Maybe it's disconnected by the fireware.

<!-- gh-comment-id:552272904 --> @fatedier commented on GitHub (Nov 11, 2019): Any log of frps? Maybe it's disconnected by the fireware.
gitea-mirror commented 2026-05-05 12:46:05 -06:00
Author
Owner
Copy link

@i542873057 commented on GitHub (Nov 11, 2019):

我也出现了相同的错误
image
运行一段时间儿会突然出现 这个错误，然后重连又好了，但是会很卡，然后过会儿又断了

<!-- gh-comment-id:552276641 --> @i542873057 commented on GitHub (Nov 11, 2019): 我也出现了相同的错误 ![image](https://user-images.githubusercontent.com/16971894/68558453-59f27200-0474-11ea-8c13-cf57ff803211.png) 运行一段时间儿会突然出现 这个错误，然后重连又好了，但是会很卡，然后过会儿又断了
gitea-mirror commented 2026-05-05 12:46:06 -06:00
Author
Owner
Copy link

@nakululusatuva commented on GitHub (Nov 11, 2019):

@fatedier Unfortunately, I forgot to set the log path on the server-side, but according to the output of "systemctl status frps" while the bug is happening, the situation is quite the same as the client, it just repeats "client login" and "client disconnect success".
It seems like its a bug since 0.24.1, After research on google I switch back to 0.24.0 on both server and client and the bug doesn't show up again (frps0.29.0+frpc0.24.0 still has the problem).
I guess it might be caused by a large number of invalid TCP requests. The client-side works 7x24, just before the bug happens, my bitcoin service on the client-side was down 2-days ago before the bug happened and I didn't notice, so the local port 8333 was closed, meanwhile, frps is still listening and a lot of TCP request was received, so that cause the crash?
It could be a kind of possibility, but this bug used to happen more than once without a situation like this.

Btw, this is my iptables configuration:
client-side

Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0           
ACCEPT     all  --  127.0.0.0/24         127.0.0.0/24        
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
ACCEPT     udp  --  10.0.0.0/8           0.0.0.0/0            udp spt:1900
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:8333
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:8333
ACCEPT     tcp  --  10.0.0.0/8           0.0.0.0/0            tcp dpt:28003
ACCEPT     udp  --  10.0.0.0/8           0.0.0.0/0            udp dpt:28003
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:28955
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:28955
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:50000
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:50000

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

server-side

Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0           
ACCEPT     all  --  127.0.0.0/24         127.0.0.0/24        
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:443
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:443
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:2222
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:2222
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:8333
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:8333
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 28000:28100
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 28000:28100
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 28955:29000
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 28955:29000

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
<!-- gh-comment-id:552292342 --> @nakululusatuva commented on GitHub (Nov 11, 2019): @fatedier Unfortunately, I forgot to set the log path on the server-side, but according to the output of "systemctl status frps" while the bug is happening, the situation is quite the same as the client, it just repeats "client login" and "client disconnect success". It seems like its a bug since 0.24.1, After research on google I switch back to 0.24.0 on both server and client and the bug doesn't show up again (frps0.29.0+frpc0.24.0 still has the problem). I guess it might be caused by a large number of invalid TCP requests. The client-side works 7x24, just before the bug happens, my bitcoin service on the client-side was down 2-days ago before the bug happened and I didn't notice, so the local port 8333 was closed, meanwhile, frps is still listening and a lot of TCP request was received, so that cause the crash? It could be a kind of possibility, but this bug used to happen more than once without a situation like this. Btw, this is my iptables configuration: client-side ``` Chain INPUT (policy DROP) target prot opt source destination ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 ACCEPT all -- 127.0.0.0/24 127.0.0.0/24 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED ACCEPT udp -- 10.0.0.0/8 0.0.0.0/0 udp spt:1900 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:8333 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:8333 ACCEPT tcp -- 10.0.0.0/8 0.0.0.0/0 tcp dpt:28003 ACCEPT udp -- 10.0.0.0/8 0.0.0.0/0 udp dpt:28003 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:28955 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:28955 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:50000 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:50000 Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination ``` server-side ``` Chain INPUT (policy DROP) target prot opt source destination ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 ACCEPT all -- 127.0.0.0/24 127.0.0.0/24 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:443 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:2222 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:2222 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:8333 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:8333 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 multiport dports 28000:28100 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 multiport dports 28000:28100 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 multiport dports 28955:29000 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 multiport dports 28955:29000 Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination ```
gitea-mirror commented 2026-05-05 12:46:06 -06:00
Author
Owner
Copy link

@fatedier commented on GitHub (Nov 11, 2019):

You should find why the client is closed from server. frps's log may have some info about it. Try to reproduce it and paste the frps log.

It's better use same version frpc and frps.

<!-- gh-comment-id:552307972 --> @fatedier commented on GitHub (Nov 11, 2019): You should find why the client is closed from server. frps's log may have some info about it. Try to reproduce it and paste the frps log. It's better use same version frpc and frps.
gitea-mirror commented 2026-05-05 12:46:06 -06:00
Author
Owner
Copy link

@AuroraDysis commented on GitHub (Nov 15, 2019):

same problem

frpc.ini

[common]
server_addr = xx.xx.xx.xx
server_port = 7700
token = xxxx

[ssh]
type = tcp
local_ip = 127.0.0.1
local_port = 22
remote_port = 7001

[nx]
type = tcp
local_ip = 127.0.0.1
local_port = 4000
remote_port = 7002

[rdp]
type = tcp
local_ip = 127.0.0.1
local_port = 3389
remote_port = 7003

frps.ini

[common]
bind_port = 7700
bind_udp_port = 7701
token = xxxx

dashboard_port = 7500
dashboard_user = xxxx
dashboard_pwd = xxxx

client side log

-- Logs begin at Fri 2019-11-15 12:21:06 GMT, end at Fri 2019-11-15 15:04:41 GMT. --
Nov 15 15:01:01 dell-t430 frpc[3090]: 2019/11/15 15:01:01 [I] [control.go:251] [e182b201dcac590b] control writer is closing
Nov 15 15:01:01 dell-t430 frpc[3090]: 2019/11/15 15:01:01 [I] [service.go:148] [e182b201dcac590b] try to reconnect to server...
Nov 15 15:01:01 dell-t430 frpc[3090]: 2019/11/15 15:01:01 [I] [service.go:249] [e182b201dcac590b] login to server success, get run id [e182b201dcac590b], server udp port [7701]
Nov 15 15:01:01 dell-t430 frpc[3090]: 2019/11/15 15:01:01 [I] [proxy_manager.go:144] [e182b201dcac590b] proxy added: [p2p_nx p2p_rdp ssh nx rdp p2p_ssh]
Nov 15 15:01:31 dell-t430 frpc[3090]: 2019/11/15 15:01:31 [I] [control.go:251] [e182b201dcac590b] control writer is closing
Nov 15 15:01:31 dell-t430 frpc[3090]: 2019/11/15 15:01:31 [E] [control.go:147] [e182b201dcac590b] work connection closed before response StartWorkConn message: EOF
Nov 15 15:01:31 dell-t430 frpc[3090]: 2019/11/15 15:01:31 [I] [service.go:148] [e182b201dcac590b] try to reconnect to server...
Nov 15 15:01:31 dell-t430 frpc[3090]: 2019/11/15 15:01:31 [I] [service.go:249] [e182b201dcac590b] login to server success, get run id [e182b201dcac590b], server udp port [7701]
Nov 15 15:01:31 dell-t430 frpc[3090]: 2019/11/15 15:01:31 [I] [proxy_manager.go:144] [e182b201dcac590b] proxy added: [p2p_nx p2p_rdp ssh nx rdp p2p_ssh]
Nov 15 15:02:01 dell-t430 frpc[3090]: 2019/11/15 15:02:01 [E] [control.go:147] [e182b201dcac590b] work connection closed before response StartWorkConn message: EOF
Nov 15 15:02:01 dell-t430 frpc[3090]: 2019/11/15 15:02:01 [I] [control.go:251] [e182b201dcac590b] control writer is closing
Nov 15 15:02:01 dell-t430 frpc[3090]: 2019/11/15 15:02:01 [I] [service.go:148] [e182b201dcac590b] try to reconnect to server...
Nov 15 15:02:01 dell-t430 frpc[3090]: 2019/11/15 15:02:01 [I] [service.go:249] [e182b201dcac590b] login to server success, get run id [e182b201dcac590b], server udp port [7701]

server side log

2019/11/15 22:53:49 [I] [service.go:372] [e182b201dcac590b] client login info: ip [114.255.218.20:10140] version [0.29.1] hostname [] os [linux] arch [amd64]
2019/11/15 22:54:19 [I] [control.go:293] [e182b201dcac590b] control writer is closing
2019/11/15 22:54:19 [I] [control.go:371] [e182b201dcac590b] client exit success
2019/11/15 22:54:19 [I] [service.go:372] [e182b201dcac590b] client login info: ip [114.255.218.20:21759] version [0.29.1] hostname [] os [linux] arch [amd64]
2019/11/15 22:54:49 [I] [control.go:293] [e182b201dcac590b] control writer is closing
2019/11/15 22:54:49 [I] [control.go:371] [e182b201dcac590b] client exit success
2019/11/15 22:54:49 [I] [service.go:372] [e182b201dcac590b] client login info: ip [114.255.218.20:22230] version [0.29.1] hostname [] os [linux] arch [amd64]
2019/11/15 22:55:19 [I] [control.go:293] [e182b201dcac590b] control writer is closing
<!-- gh-comment-id:554395480 --> @AuroraDysis commented on GitHub (Nov 15, 2019): same problem frpc.ini ``` [common] server_addr = xx.xx.xx.xx server_port = 7700 token = xxxx [ssh] type = tcp local_ip = 127.0.0.1 local_port = 22 remote_port = 7001 [nx] type = tcp local_ip = 127.0.0.1 local_port = 4000 remote_port = 7002 [rdp] type = tcp local_ip = 127.0.0.1 local_port = 3389 remote_port = 7003 ``` frps.ini ``` [common] bind_port = 7700 bind_udp_port = 7701 token = xxxx dashboard_port = 7500 dashboard_user = xxxx dashboard_pwd = xxxx ``` client side log ``` -- Logs begin at Fri 2019-11-15 12:21:06 GMT, end at Fri 2019-11-15 15:04:41 GMT. -- Nov 15 15:01:01 dell-t430 frpc[3090]: 2019/11/15 15:01:01 [I] [control.go:251] [e182b201dcac590b] control writer is closing Nov 15 15:01:01 dell-t430 frpc[3090]: 2019/11/15 15:01:01 [I] [service.go:148] [e182b201dcac590b] try to reconnect to server... Nov 15 15:01:01 dell-t430 frpc[3090]: 2019/11/15 15:01:01 [I] [service.go:249] [e182b201dcac590b] login to server success, get run id [e182b201dcac590b], server udp port [7701] Nov 15 15:01:01 dell-t430 frpc[3090]: 2019/11/15 15:01:01 [I] [proxy_manager.go:144] [e182b201dcac590b] proxy added: [p2p_nx p2p_rdp ssh nx rdp p2p_ssh] Nov 15 15:01:31 dell-t430 frpc[3090]: 2019/11/15 15:01:31 [I] [control.go:251] [e182b201dcac590b] control writer is closing Nov 15 15:01:31 dell-t430 frpc[3090]: 2019/11/15 15:01:31 [E] [control.go:147] [e182b201dcac590b] work connection closed before response StartWorkConn message: EOF Nov 15 15:01:31 dell-t430 frpc[3090]: 2019/11/15 15:01:31 [I] [service.go:148] [e182b201dcac590b] try to reconnect to server... Nov 15 15:01:31 dell-t430 frpc[3090]: 2019/11/15 15:01:31 [I] [service.go:249] [e182b201dcac590b] login to server success, get run id [e182b201dcac590b], server udp port [7701] Nov 15 15:01:31 dell-t430 frpc[3090]: 2019/11/15 15:01:31 [I] [proxy_manager.go:144] [e182b201dcac590b] proxy added: [p2p_nx p2p_rdp ssh nx rdp p2p_ssh] Nov 15 15:02:01 dell-t430 frpc[3090]: 2019/11/15 15:02:01 [E] [control.go:147] [e182b201dcac590b] work connection closed before response StartWorkConn message: EOF Nov 15 15:02:01 dell-t430 frpc[3090]: 2019/11/15 15:02:01 [I] [control.go:251] [e182b201dcac590b] control writer is closing Nov 15 15:02:01 dell-t430 frpc[3090]: 2019/11/15 15:02:01 [I] [service.go:148] [e182b201dcac590b] try to reconnect to server... Nov 15 15:02:01 dell-t430 frpc[3090]: 2019/11/15 15:02:01 [I] [service.go:249] [e182b201dcac590b] login to server success, get run id [e182b201dcac590b], server udp port [7701] ``` server side log ``` 2019/11/15 22:53:49 [I] [service.go:372] [e182b201dcac590b] client login info: ip [114.255.218.20:10140] version [0.29.1] hostname [] os [linux] arch [amd64] 2019/11/15 22:54:19 [I] [control.go:293] [e182b201dcac590b] control writer is closing 2019/11/15 22:54:19 [I] [control.go:371] [e182b201dcac590b] client exit success 2019/11/15 22:54:19 [I] [service.go:372] [e182b201dcac590b] client login info: ip [114.255.218.20:21759] version [0.29.1] hostname [] os [linux] arch [amd64] 2019/11/15 22:54:49 [I] [control.go:293] [e182b201dcac590b] control writer is closing 2019/11/15 22:54:49 [I] [control.go:371] [e182b201dcac590b] client exit success 2019/11/15 22:54:49 [I] [service.go:372] [e182b201dcac590b] client login info: ip [114.255.218.20:22230] version [0.29.1] hostname [] os [linux] arch [amd64] 2019/11/15 22:55:19 [I] [control.go:293] [e182b201dcac590b] control writer is closing ```
gitea-mirror commented 2026-05-05 12:46:07 -06:00
Author
Owner
Copy link

@fatedier commented on GitHub (Nov 18, 2019):

@AuroraDysis set tls_enable = true or protocol = kcp.

Maybe it's blocked by the network provider.

<!-- gh-comment-id:554834192 --> @fatedier commented on GitHub (Nov 18, 2019): @AuroraDysis set `tls_enable = true` or `protocol = kcp`. Maybe it's blocked by the network provider.
gitea-mirror commented 2026-05-05 12:46:07 -06:00
Author
Owner
Copy link

@AuroraDysis commented on GitHub (Nov 18, 2019):

@fatedier This error happens by chance. I can fix it by restarting my frps docker when it happens. Anyway, I will try the configs you suggested and see if the error still exists. Thanks for your help.

<!-- gh-comment-id:555265764 --> @AuroraDysis commented on GitHub (Nov 18, 2019): @fatedier This error happens by chance. I can fix it by restarting my frps docker when it happens. Anyway, I will try the configs you suggested and see if the error still exists. Thanks for your help.
gitea-mirror commented 2026-05-05 12:46:07 -06:00
Author
Owner
Copy link

@befantasy commented on GitHub (Feb 16, 2020):

很早之前就发现了这个问题。。。感觉好像是被GFW干扰了。
不访问FRP服务的话，一般不会出这个error。经常一访问立即就出。

<!-- gh-comment-id:586697341 --> @befantasy commented on GitHub (Feb 16, 2020): 很早之前就发现了这个问题。。。感觉好像是被GFW干扰了。 不访问FRP服务的话，一般不会出这个error。经常一访问立即就出。
gitea-mirror commented 2026-05-05 12:46:08 -06:00
Author
Owner
Copy link

@fatedier commented on GitHub (Feb 16, 2020):

@befantasy 外层再套一层加密工具中转- -

<!-- gh-comment-id:586698358 --> @fatedier commented on GitHub (Feb 16, 2020): @befantasy 外层再套一层加密工具中转- -
gitea-mirror commented 2026-05-05 12:46:08 -06:00
Author
Owner
Copy link

@befantasy commented on GitHub (Feb 16, 2020):

没注意最近的版本增加了tls_enable = true这个功能。
刚才试了试，好像开了以后好了很多。

@befantasy 外层再套一层加密工具中转- -

<!-- gh-comment-id:586719694 --> @befantasy commented on GitHub (Feb 16, 2020): 没注意最近的版本增加了tls_enable = true这个功能。 刚才试了试，好像开了以后好了很多。 > @befantasy 外层再套一层加密工具中转- -
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
dev
new
master
copilot/review-pull-request-5198
v0.68.1
v0.68.0
v0.67.0
v0.66.0
v0.65.0
v0.64.0
v0.63.0
v0.62.1
v0.62.0
v0.61.2
v0.61.1
v0.61.0
v0.60.0
v0.59.0
v0.58.1
v0.58.0
v0.57.0
v0.56.0
v0.55.1
v0.55.0
v0.54.0
v0.53.2
v0.53.1
v0.53.0
v0.52.3
v0.52.2
v0.52.1
v0.52.0
v0.51.3
v0.51.2
v0.51.1
v0.51.0
v0.50.0
v0.49.0
v0.48.0
v0.47.0
v0.46.1
v0.46.0
v0.45.0
v0.44.0
v0.43.0
v0.42.0
v0.41.0
v0.40.0
v0.39.1
v0.39.0
v0.38.0
v0.37.1
v0.37.0
v0.36.2
v0.36.1
v0.36.0
v0.35.1
v0.35.0
v0.34.3
v0.34.2
v0.34.1
v0.34.0
v0.33.0
v0.32.1
v0.32.0
v0.31.2
v0.31.1
v0.31.0
v0.30.0
v0.29.1
v0.29.0
v0.28.2
v0.28.1
v0.28.0
v0.27.1
v0.27.0
v0.26.0
v0.25.3
v0.25.2
v0.25.1
v0.25.0
v0.24.1
v0.24.0
v0.23.3
v0.23.2
v0.23.1
v0.23.0
v0.22.0
v0.21.0
v0.20.0
v0.19.1
v0.19.0
v0.18.0
v0.17.0
v0.16.1
v0.16.0
v0.15.1
v0.15.0
v0.14.1
v0.14.0
v0.13.0
v0.12.0
v0.11.0
v0.10.0
v0.9.3
v0.9.2
v0.9.1
v0.9.0
v0.8.1
v0.8.0
v0.7.0
v0.6.0
v0.5.0
v0.3.0
v0.2.0
v0.1.0
Labels
Clear labels   
In Progress

   
WIP

   
WaitingForInfo

   
bug

   
doc

   
duplicate

   
easy

   
enhancement

   
future

   
help wanted

   
invalid

   
lifecycle/stale

   
need-issue-template

   
need-usage-help

   
no plan

   
proposal

   
pull-request

Mirrored from GitHub Pull Request

  
question

   
todo
No labels
In Progress
WIP
WaitingForInfo
bug
doc
duplicate
easy
enhancement
future
help wanted
invalid
lifecycle/stale
need-issue-template
need-usage-help
no plan
proposal
pull-request
question
todo
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/frp#1191
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?