[GH-ISSUE #510] authorization timeout 问题 #391

New issue

Closed

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

gitea-mirror commented

2026-05-05 12:12:29 -06:00

Owner

Originally created by @qz812371248 on GitHub (Nov 3, 2017).
Original GitHub issue: https://github.com/fatedier/frp/issues/510

Issue is only used for submiting bug report and documents typo. If there are same issues or answers can be found in documents, we will close it directly.
(为了节约时间，提高处理问题的效率，不按照格式填写的 issue 将会直接关闭。)

Use the commands below to provide key information from your environment:

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

What operating system and processor architecture are you using (go env)?
服务端:
Linux izuf6ex 3.10.0-514.6.2.el7.x86_64 #1 SMP Thu Feb 23 03:04:39 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

客户端:
Linux RT-AC54U 3.4.113 #2 Sun Oct 22 11:38:56 CST 2017 mips GNU/Linux

Configures you used:
服务端配置(frps.ini):
bind_port = 7000
kcp_bind_port = 7001
vhost_http_port = 80
vhost_https_port = 443
privilege_token = abcdefg
tcp_mux = true
max_pool_count = 50
dashboard_port = 7500
dashboard_user = admin
dashboard_pwd = admin
log_file = ./frps.log
log_level = info
log_max_days = 3

客户端配置(frpc.ini):
[common]
privilege_token = abcdefg
server_addr = 139.196.XXX.XXX
tcp_mux = true
server_port = 7000

[miwifi]
type = http
local_port = 80
local_ip = 192.168.123.1
subdomain = miwifi

Steps to reproduce the issue:

启动服务端: ./frps -c ./frps.ini
启动客户端: ./frps -c ./frpc.ini
客户端日志:
2017/11/03 01:34:50 [E] [control.go:267] authorization timeout
2017/11/03 01:34:50 [W] [control.go:121] login to server failed: authorization timeout
authorization timeout

服务端日志:
2017/11/03 12:47:29 [I] [service.go:230] client login info: ip [123.82.184.129:34886] version [0.13.0] hostname [] os [linux] arch [mipsle]
2017/11/03 12:47:29 [W] [service.go:174] authorization timeout
2017/11/03 12:47:29 [W] [service.go:214] Accept new mux stream error: broken pipe

备注:本来是还没解决问题然后把日志粘贴上来的,发现日志上的客户端和服务器的时间不一致,于是同步了客户端时间在启动结果能正常使用了

Originally created by @qz812371248 on GitHub (Nov 3, 2017). Original GitHub issue: https://github.com/fatedier/frp/issues/510 Issue is only used for submiting bug report and documents typo. If there are same issues or answers can be found in documents, we will close it directly. (为了节约时间，提高处理问题的效率，不按照格式填写的 issue 将会直接关闭。) Use the commands below to provide key information from your environment: **What version of frp are you using (./frpc -v or ./frps -v)?** version [0.13.0] **What operating system and processor architecture are you using (`go env`)?** 服务端: Linux izuf6ex 3.10.0-514.6.2.el7.x86_64 #1 SMP Thu Feb 23 03:04:39 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux 客户端: Linux RT-AC54U 3.4.113 #2 Sun Oct 22 11:38:56 CST 2017 mips GNU/Linux **Configures you used:** 服务端配置(frps.ini): bind_port = 7000 kcp_bind_port = 7001 vhost_http_port = 80 vhost_https_port = 443 privilege_token = abcdefg tcp_mux = true max_pool_count = 50 dashboard_port = 7500 dashboard_user = admin dashboard_pwd = admin log_file = ./frps.log log_level = info log_max_days = 3 客户端配置(frpc.ini): [common] privilege_token = abcdefg server_addr = 139.196.XXX.XXX tcp_mux = true server_port = 7000 [miwifi] type = http local_port = 80 local_ip = 192.168.123.1 subdomain = miwifi **Steps to reproduce the issue:** 1. 启动服务端: ./frps -c ./frps.ini 2. 启动客户端: ./frps -c ./frpc.ini 3. 客户端日志: 2017/11/03 01:34:50 [E] [control.go:267] authorization timeout 2017/11/03 01:34:50 [W] [control.go:121] login to server failed: authorization timeout authorization timeout 服务端日志: 2017/11/03 12:47:29 [I] [service.go:230] client login info: ip [123.82.184.129:34886] version [0.13.0] hostname [] os [linux] arch [mipsle] 2017/11/03 12:47:29 [W] [service.go:174] authorization timeout 2017/11/03 12:47:29 [W] [service.go:214] Accept new mux stream error: broken pipe 备注:本来是还没解决问题然后把日志粘贴上来的,发现日志上的客户端和服务器的时间不一致,于是同步了客户端时间在启动结果能正常使用了

gitea-mirror closed this issue

2026-05-05 12:12:31 -06:00

gitea-mirror commented

2026-05-05 12:12:33 -06:00

Author

Owner

@fatedier commented on GitHub (Nov 3, 2017):

所以你的问题已经自己解决了这个问题。

@fatedier commented on GitHub (Nov 3, 2017): 所以你的问题已经自己解决了这个问题。

gitea-mirror commented

2026-05-05 12:12:35 -06:00

Author

Owner

@zhangs2018 commented on GitHub (Jan 6, 2018):

我也出现了你的这个问题，按照你的方法把客户端的时间调好就可以正常启动了！

@zhangs2018 commented on GitHub (Jan 6, 2018): 我也出现了你的这个问题，按照你的方法把客户端的时间调好就可以正常启动了！

gitea-mirror commented

2026-05-05 12:12:36 -06:00

Author

Owner

@dong-zeyu commented on GitHub (Jul 26, 2018):

所以说问题是：如果客户端和服务端时间不一致，那么就会出现authorization timeout错误，请问要求客户端和服务端时间一致是程序正常运行所必须的么，如果不是的话，建议取消或Bypass这个限制，因为在某些非PC的硬件平台上，时间不一致是常有的事情

PS: 在0.20版本中，这个特性依旧存在
查看了下代码，好像有点懂了
629f2856b1/server/service.go (L316-L319)
没有细看，是不是只要把auth_timeout设成0就不会有这样的问题了，所以还是有点不懂这个auth_timeout存在的意义是什么
-------------Update-------------
看了README，有点懂了

@dong-zeyu commented on GitHub (Jul 26, 2018): 所以说问题是：如果客户端和服务端时间不一致，那么就会出现authorization timeout错误，请问要求客户端和服务端时间一致是程序正常运行所必须的么，如果不是的话，建议取消或Bypass这个限制，因为在某些非PC的硬件平台上，时间不一致是常有的事情 PS: 在0.20版本中，这个特性依旧存在查看了下代码，好像有点懂了 https://github.com/fatedier/frp/blob/629f2856b1d65641d494e538f4197bb11020d6f0/server/service.go#L316-L319 没有细看，是不是只要把`auth_timeout`设成0就不会有这样的问题了，所以还是有点不懂这个`auth_timeout`存在的意义是什么 -------------Update------------- 看了README，有点懂了