github-starred/frp

Fork 0

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

[GH-ISSUE #3050] 配置了tls_enable = true之后，依旧出现login to server failed: EOF 这个错误 #2440

New issue

Closed

opened 2026-05-05 13:34:10 -06:00 by gitea-mirror · 5 comments

gitea-mirror commented

2026-05-05 13:34:10 -06:00

Owner

Originally created by @lanjing99 on GitHub (Aug 8, 2022).
Original GitHub issue: https://github.com/fatedier/frp/issues/3050

Bug Description

在配置了tls_enable = true之后，依旧出现login to server failed: EOF 这个错误

frpc Version

0.44

frps Version

0.44

System Architecture

linuxj/amd64

Configurations

服务端 frps.ini 配置如下

[common]
bind_port = 7000
tls_enable = true

客户端 frpc.ini 配置如下：

[common]
# 公网环境
server_addr = 183.56.xx.xx
# 内网环境
#server_addr = 10.1.3.86    

server_port = 7000
tls_enable = true


[ssh]
type = tcp
local_ip = 127.0.0.1
local_port = 2222
remote_port = 6000

Logs

No response

Steps to reproduce

基于frp 0.44版本搭建中转服务，遇到了如下错误：
[W] [service.go:128] login to server failed: EOF
网络上找到 https://blog.phpgao.com/frp_tcp_reset.html 这篇链接，添加依旧无效
tls_enable = true 配置依旧无效。
服务端 frps.ini 配置如下

[common]
bind_port = 7000
tls_enable = true

客户端 frpc.ini 配置如下：

[common]
# 公网环境
server_addr = 183.56.xx.xx
# 内网环境
#server_addr = 10.1.3.86    

server_port = 7000
tls_enable = true


[ssh]
type = tcp
local_ip = 127.0.0.1
local_port = 2222
remote_port = 6000

将frps服务配置在一个公网的frps服务器上。

客户端通过在公司局域网内通过内网IP 可以访问frps
客户端通过在公司局域网内通过公网绑定的弹性IP 访问frps，提示 login to server failed: EOF
通过手机热点，使用公网弹性IP可以访问frps。

使用tls_enable = true选项抓包如下
在frpc client上抓包

在frps服务器上使用tcpdump抓包

root@yx-0210269:~# tcpdump -iany port 7000 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes

16:34:55.168435 IP 219.131.131.150.51845 > 10.1.3.86.7000: Flags [SEW], seq 3846460603, win 65535, options [mss 1380,nop,nop,nop,nop,nop,nop,TS val 390480843 ecr 0,sackOK,eol], length 0
16:34:55.168499 IP 10.1.3.86.7000 > 219.131.131.150.51845: Flags [S.E], seq 4135882854, ack 3846460604, win 65160, options [mss 1460,sackOK,TS val 3833665930 ecr 390480843], length 0
16:34:55.179191 IP 219.131.131.150.51845 > 10.1.3.86.7000: Flags [.], ack 1, win 65535, options [nop,nop,TS val 390480856 ecr 3833665930], length 0
16:34:55.183336 IP 219.131.131.150.51845 > 10.1.3.86.7000: Flags [P.], seq 1:2, ack 1, win 65535, options [nop,nop,TS val 390480860 ecr 3833665930], length 1
16:34:55.183373 IP 10.1.3.86.7000 > 219.131.131.150.51845: Flags [.], ack 2, win 65159, options [nop,nop,TS val 3833665944 ecr 390480860], length 0
16:34:55.187076 IP 219.131.131.150.51845 > 10.1.3.86.7000: Flags [P.], seq 2:241, ack 1, win 65535, options [nop,nop,TS val 390480864 ecr 3833665930], length 239
16:34:55.187110 IP 10.1.3.86.7000 > 219.131.131.150.51845: Flags [.], ack 241, win 64920, options [nop,nop,TS val 3833665948 ecr 390480864], length 0
16:34:55.187888 IP 10.1.3.86.7000 > 219.131.131.150.51845: Flags [P.], seq 1:796, ack 241, win 64920, options [nop,nop,TS val 3833665949 ecr 390480864], length 795
16:34:55.194800 IP 219.131.131.150.51845 > 10.1.3.86.7000: Flags [.], ack 796, win 65535, options [nop,nop,TS val 390480871 ecr 3833665949], length 0
16:34:55.196866 IP 219.131.131.150.51845 > 10.1.3.86.7000: Flags [R.], seq 241, ack 796, win 0, length 0
16:34:55.196917 IP 219.131.131.150.51845 > 10.1.3.86.7000: Flags [R.], seq 1701, ack 796, win 0, length 0
16:34:55.196936 IP 219.131.131.150.51845 > 10.1.3.86.7000: Flags [R.], seq 4621, ack 796, win 0, length 0

客户端和服务器的有几个包对应不上，看来是客户端内网这边的NAT做了一些操作。

未使用tls_enable = true选项，客户端配置去掉tls_enable = true抓包如下

在frps服务器上使用tcpdump抓包

root@yx-0210269:~/frp/frp_0.44.0_linux_amd64# tcpdump -iany port 7000 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes

16:48:03.708851 IP 219.131.131.150.52143 > 10.1.3.86.7000: Flags [S], seq 3444434787, win 65535, options [mss 1380,nop,nop,nop,nop,nop,nop,TS val 1458914482 ecr 0,sackOK,eol], length 0
16:48:03.708924 IP 10.1.3.86.7000 > 219.131.131.150.52143: Flags [S.], seq 706244039, ack 3444434788, win 65160, options [mss 1460,sackOK,TS val 3834454470 ecr 1458914482], length 0
16:48:03.715935 IP 219.131.131.150.52143 > 10.1.3.86.7000: Flags [.], ack 1, win 65535, options [nop,nop,TS val 1458914494 ecr 3834454470], length 0
16:48:03.717005 IP 219.131.131.150.52143 > 10.1.3.86.7000: Flags [P.], seq 1:13, ack 1, win 65535, options [nop,nop,TS val 1458914495 ecr 3834454470], length 12
16:48:03.717049 IP 10.1.3.86.7000 > 219.131.131.150.52143: Flags [.], ack 13, win 65148, options [nop,nop,TS val 3834454478 ecr 1458914495], length 0
16:48:03.717263 IP 10.1.3.86.7000 > 219.131.131.150.52143: Flags [P.], seq 1:13, ack 13, win 65148, options [nop,nop,TS val 3834454478 ecr 1458914495], length 12
16:48:03.717968 IP 219.131.131.150.52143 > 10.1.3.86.7000: Flags [P.], seq 13:25, ack 1, win 65535, options [nop,nop,TS val 1458914495 ecr 3834454470], length 12
16:48:03.717990 IP 10.1.3.86.7000 > 219.131.131.150.52143: Flags [.], ack 25, win 65136, options [nop,nop,TS val 3834454479 ecr 1458914495], length 0
16:48:03.719305 IP 219.131.131.150.52143 > 10.1.3.86.7000: Flags [R.], seq 1461, ack 1, win 0, length 0
16:48:03.719324 IP 10.1.3.86.7000 > 219.131.131.150.52143: Flags [.], ack 25, win 65136, options [nop,nop,TS val 3834454480 ecr 1458914495], length 0
16:48:03.719329 IP 219.131.131.150.52143 > 10.1.3.86.7000: Flags [R.], seq 4381, ack 1, win 0, length 0
16:48:03.926322 IP 10.1.3.86.7000 > 219.131.131.150.52143: Flags [P.], seq 1:13, ack 25, win 65136, options [nop,nop,TS val 3834454687 ecr 1458914495], length 12

可以看到第5,6两个数据包（9,10两行），frps向frpc回复响应数据包，但是在客户端的第7,8,9却收到rst数据包，因为使用手机热点通过弹性公网IP可以访问frps，所以猜测是 frpc所在的NAT网络禁用了frp服务（还不知道这个怎么实现。）。
如果能在frpc网络的公网IP:219.131.131.150 上抓包，就能判断rst数据包是NAT客户端发送的，还是frps所在的公网发送的。目前倾向于是frpc所在的网络禁用了frp。

Affected area

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

Originally created by @lanjing99 on GitHub (Aug 8, 2022). Original GitHub issue: https://github.com/fatedier/frp/issues/3050 ### Bug Description 在配置了tls_enable = true之后，依旧出现login to server failed: EOF 这个错误 ### frpc Version 0.44 ### frps Version 0.44 ### System Architecture linuxj/amd64 ### Configurations 服务端 frps.ini 配置如下 ``` [common] bind_port = 7000 tls_enable = true ``` 客户端 frpc.ini 配置如下： ``` [common] # 公网环境 server_addr = 183.56.xx.xx # 内网环境 #server_addr = 10.1.3.86 server_port = 7000 tls_enable = true [ssh] type = tcp local_ip = 127.0.0.1 local_port = 2222 remote_port = 6000 ``` ### Logs _No response_ ### Steps to reproduce 基于frp 0.44版本搭建中转服务，遇到了如下错误： [W] [service.go:128] login to server failed: EOF 网络上找到 https://blog.phpgao.com/frp_tcp_reset.html 这篇链接，添加依旧无效 tls_enable = true 配置依旧无效。服务端 frps.ini 配置如下 ``` [common] bind_port = 7000 tls_enable = true ``` 客户端 frpc.ini 配置如下： ``` [common] # 公网环境 server_addr = 183.56.xx.xx # 内网环境 #server_addr = 10.1.3.86 server_port = 7000 tls_enable = true [ssh] type = tcp local_ip = 127.0.0.1 local_port = 2222 remote_port = 6000 ``` 将frps服务配置在一个公网的frps服务器上。 1. 客户端通过在公司局域网内通过内网IP 可以访问frps 2. 客户端通过在公司局域网内通过公网绑定的弹性IP 访问frps，提示 login to server failed: EOF 3. 通过手机热点，使用公网弹性IP可以访问frps。使用`tls_enable = true`选项抓包如下在frpc client上抓包 ![image](https://user-images.githubusercontent.com/4648038/183380926-954c1efe-481e-4ce8-bf87-0410b8f1c7e0.png) 在frps服务器上使用tcpdump抓包 ``` root@yx-0210269:~# tcpdump -iany port 7000 -n tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes 16:34:55.168435 IP 219.131.131.150.51845 > 10.1.3.86.7000: Flags [SEW], seq 3846460603, win 65535, options [mss 1380,nop,nop,nop,nop,nop,nop,TS val 390480843 ecr 0,sackOK,eol], length 0 16:34:55.168499 IP 10.1.3.86.7000 > 219.131.131.150.51845: Flags [S.E], seq 4135882854, ack 3846460604, win 65160, options [mss 1460,sackOK,TS val 3833665930 ecr 390480843], length 0 16:34:55.179191 IP 219.131.131.150.51845 > 10.1.3.86.7000: Flags [.], ack 1, win 65535, options [nop,nop,TS val 390480856 ecr 3833665930], length 0 16:34:55.183336 IP 219.131.131.150.51845 > 10.1.3.86.7000: Flags [P.], seq 1:2, ack 1, win 65535, options [nop,nop,TS val 390480860 ecr 3833665930], length 1 16:34:55.183373 IP 10.1.3.86.7000 > 219.131.131.150.51845: Flags [.], ack 2, win 65159, options [nop,nop,TS val 3833665944 ecr 390480860], length 0 16:34:55.187076 IP 219.131.131.150.51845 > 10.1.3.86.7000: Flags [P.], seq 2:241, ack 1, win 65535, options [nop,nop,TS val 390480864 ecr 3833665930], length 239 16:34:55.187110 IP 10.1.3.86.7000 > 219.131.131.150.51845: Flags [.], ack 241, win 64920, options [nop,nop,TS val 3833665948 ecr 390480864], length 0 16:34:55.187888 IP 10.1.3.86.7000 > 219.131.131.150.51845: Flags [P.], seq 1:796, ack 241, win 64920, options [nop,nop,TS val 3833665949 ecr 390480864], length 795 16:34:55.194800 IP 219.131.131.150.51845 > 10.1.3.86.7000: Flags [.], ack 796, win 65535, options [nop,nop,TS val 390480871 ecr 3833665949], length 0 16:34:55.196866 IP 219.131.131.150.51845 > 10.1.3.86.7000: Flags [R.], seq 241, ack 796, win 0, length 0 16:34:55.196917 IP 219.131.131.150.51845 > 10.1.3.86.7000: Flags [R.], seq 1701, ack 796, win 0, length 0 16:34:55.196936 IP 219.131.131.150.51845 > 10.1.3.86.7000: Flags [R.], seq 4621, ack 796, win 0, length 0 ``` 客户端和服务器的有几个包对应不上，看来是客户端内网这边的NAT做了一些操作。未使用`tls_enable = true`选项，客户端配置去掉tls_enable = true抓包如下 ![image](https://user-images.githubusercontent.com/4648038/183380977-4da25a6d-69d2-4dbf-b52b-f59e84eaf490.png) 在frps服务器上使用tcpdump抓包 ``` root@yx-0210269:~/frp/frp_0.44.0_linux_amd64# tcpdump -iany port 7000 -n tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes 16:48:03.708851 IP 219.131.131.150.52143 > 10.1.3.86.7000: Flags [S], seq 3444434787, win 65535, options [mss 1380,nop,nop,nop,nop,nop,nop,TS val 1458914482 ecr 0,sackOK,eol], length 0 16:48:03.708924 IP 10.1.3.86.7000 > 219.131.131.150.52143: Flags [S.], seq 706244039, ack 3444434788, win 65160, options [mss 1460,sackOK,TS val 3834454470 ecr 1458914482], length 0 16:48:03.715935 IP 219.131.131.150.52143 > 10.1.3.86.7000: Flags [.], ack 1, win 65535, options [nop,nop,TS val 1458914494 ecr 3834454470], length 0 16:48:03.717005 IP 219.131.131.150.52143 > 10.1.3.86.7000: Flags [P.], seq 1:13, ack 1, win 65535, options [nop,nop,TS val 1458914495 ecr 3834454470], length 12 16:48:03.717049 IP 10.1.3.86.7000 > 219.131.131.150.52143: Flags [.], ack 13, win 65148, options [nop,nop,TS val 3834454478 ecr 1458914495], length 0 16:48:03.717263 IP 10.1.3.86.7000 > 219.131.131.150.52143: Flags [P.], seq 1:13, ack 13, win 65148, options [nop,nop,TS val 3834454478 ecr 1458914495], length 12 16:48:03.717968 IP 219.131.131.150.52143 > 10.1.3.86.7000: Flags [P.], seq 13:25, ack 1, win 65535, options [nop,nop,TS val 1458914495 ecr 3834454470], length 12 16:48:03.717990 IP 10.1.3.86.7000 > 219.131.131.150.52143: Flags [.], ack 25, win 65136, options [nop,nop,TS val 3834454479 ecr 1458914495], length 0 16:48:03.719305 IP 219.131.131.150.52143 > 10.1.3.86.7000: Flags [R.], seq 1461, ack 1, win 0, length 0 16:48:03.719324 IP 10.1.3.86.7000 > 219.131.131.150.52143: Flags [.], ack 25, win 65136, options [nop,nop,TS val 3834454480 ecr 1458914495], length 0 16:48:03.719329 IP 219.131.131.150.52143 > 10.1.3.86.7000: Flags [R.], seq 4381, ack 1, win 0, length 0 16:48:03.926322 IP 10.1.3.86.7000 > 219.131.131.150.52143: Flags [P.], seq 1:13, ack 25, win 65136, options [nop,nop,TS val 3834454687 ecr 1458914495], length 12 ``` 可以看到第5,6两个数据包（9,10两行），frps向frpc回复响应数据包，但是在客户端的第7,8,9却收到rst数据包，因为使用手机热点通过弹性公网IP可以访问frps，所以猜测是 frpc所在的NAT网络禁用了frp服务（还不知道这个怎么实现。）。如果能在frpc网络的公网IP:219.131.131.150 上抓包，就能判断rst数据包是NAT客户端发送的，还是frps所在的公网发送的。目前倾向于是frpc所在的网络禁用了frp。 ### 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 13:34:11 -06:00

gitea-mirror commented

2026-05-05 13:34:13 -06:00

Author

Owner

@fatedier commented on GitHub (Aug 8, 2022):

写的很好，分析的也很好。

@fatedier commented on GitHub (Aug 8, 2022): 写的很好，分析的也很好。

gitea-mirror commented

2026-05-05 13:34:13 -06:00

Author

Owner

@Becods commented on GitHub (Aug 8, 2022):

大概率是防火墙禁止了frp

特征基本上均在这里，可以自己修改打包尝试一下

4af85da0c2/pkg/msg/msg.go (L64-L195)

此外

建议不要在公司禁止的情况下使用，安全风险和后果需要自负。

@Becods commented on GitHub (Aug 8, 2022): 大概率是防火墙禁止了frp 特征基本上均在这里，可以自己修改打包尝试一下 https://github.com/fatedier/frp/blob/4af85da0c2c6eb981142a8fdb44f885d26cb9d08/pkg/msg/msg.go#L64-L195 此外 > 建议不要在公司禁止的情况下使用，安全风险和后果需要自负。

gitea-mirror commented

2026-05-05 13:34:14 -06:00

Author

Owner

@lanjing99 commented on GitHub (Aug 9, 2022):

大概率是防火墙禁止了frp

特征基本上均在这里，可以自己修改打包尝试一下

4af85da0c2/pkg/msg/msg.go (L64-L195)

此外

建议不要在公司禁止的情况下使用，安全风险和后果需要自负。

收到，谢谢！我更改一下相关代码测试一下。
上午找我们公司的网管，他配置了一下规则允许frp的流量通过就可以连上了。

我有三个问题请教一下：

防火墙是根据多个数据包的特征来过滤的吧，基于端口估计不行，因为我们后台的端口可以变化的。
frpc和frps收到的reset包应该都是防火墙向它们发送的吧。虽然在客户端显示的是frps向frpc发送的reset包，我怀疑是在经过防火墙的时候，防火墙在做NAT转换之后发了reset数据包。
使用tls_enable之前可以，是不是因为对数据加密，防火墙看不到应用层数据的内容，所以无法过滤？现在设置了tls_enable也不行，还有什么方式能绕过防火墙吗？

@lanjing99 commented on GitHub (Aug 9, 2022): > 大概率是防火墙禁止了frp > > 特征基本上均在这里，可以自己修改打包尝试一下 > > https://github.com/fatedier/frp/blob/4af85da0c2c6eb981142a8fdb44f885d26cb9d08/pkg/msg/msg.go#L64-L195 > > 此外 > > > 建议不要在公司禁止的情况下使用，安全风险和后果需要自负。收到，谢谢！我更改一下相关代码测试一下。上午找我们公司的网管，他配置了一下规则允许frp的流量通过就可以连上了。我有三个问题请教一下： 1. 防火墙是根据多个数据包的特征来过滤的吧，基于端口估计不行，因为我们后台的端口可以变化的。 2. frpc和frps收到的reset包应该都是防火墙向它们发送的吧。虽然在客户端显示的是frps向frpc发送的reset包，我怀疑是在经过防火墙的时候，防火墙在做NAT转换之后发了reset数据包。 3. 使用tls_enable之前可以，是不是因为对数据加密，防火墙看不到应用层数据的内容，所以无法过滤？现在设置了tls_enable也不行，还有什么方式能绕过防火墙吗？

gitea-mirror commented

2026-05-05 13:34:15 -06:00

Author

Owner

@lanjing99 commented on GitHub (Aug 9, 2022):

是公司的防火墙规则禁用了frp，开启之后就可以访问了。

@lanjing99 commented on GitHub (Aug 9, 2022): 是公司的防火墙规则禁用了frp，开启之后就可以访问了。

gitea-mirror commented

2026-05-05 13:34:16 -06:00

Author

Owner

@zhangsean commented on GitHub (Sep 22, 2022):

大概率是防火墙禁止了frp

特征基本上均在这里，可以自己修改打包尝试一下

4af85da0c2/pkg/msg/msg.go (L64-L195)

此外

建议不要在公司禁止的情况下使用，安全风险和后果需要自负。

我所在的项目用到frp被深信服防火墙拦截了，请问有修改握手消息代码，可以成功绕过防火墙拦截的案例吗？

@zhangsean commented on GitHub (Sep 22, 2022): > 大概率是防火墙禁止了frp > > 特征基本上均在这里，可以自己修改打包尝试一下 > > https://github.com/fatedier/frp/blob/4af85da0c2c6eb981142a8fdb44f885d26cb9d08/pkg/msg/msg.go#L64-L195 > > 此外 > > > 建议不要在公司禁止的情况下使用，安全风险和后果需要自负。我所在的项目用到frp被深信服防火墙拦截了，请问有修改握手消息代码，可以成功绕过防火墙拦截的案例吗？