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 #3270] [Feature Request] 希望可以自行设定 frpc 最大超时时间（maxDelayTime） #2622

New issue
Closed
opened 2026-05-05 13:41:27 -06:00 by gitea-mirror · 9 comments
gitea-mirror commented 2026-05-05 13:41:27 -06:00
Owner
Copy link

Originally created by @suiahae on GitHub (Jan 26, 2023).
Original GitHub issue: https://github.com/fatedier/frp/issues/3270

Describe the feature request

目前 frpc 最大超时时间（maxDelayTime）在代码 client/service.go#L171 中被设为 20s 且无法通过配置文件更改。

某些网络环境下，客户端与服务器间会出现长达数小时的断线，此时 20s 就显得有些短了。

Describe alternatives you've considered

No response

Affected area

  • Docs
  • Installation
  • Performance and Scalability
  • Security
  • User Experience
  • Test and Release
  • Developer Infrastructure
  • Client Plugin
  • Server Plugin
  • Extensions
  • Others
Originally created by @suiahae on GitHub (Jan 26, 2023). Original GitHub issue: https://github.com/fatedier/frp/issues/3270 ### Describe the feature request 目前 frpc 最大超时时间（maxDelayTime）在代码 [client/service.go#L171](https://github.dev/fatedier/frp/blob/0eecab06c17d69ba11a84162aae35ed7d94f0423/client/service.go#L171) 中被设为 20s 且无法通过配置文件更改。 某些网络环境下，客户端与服务器间会出现长达数小时的断线，此时 20s 就显得有些短了。 ### Describe alternatives you've considered _No response_ ### Affected area - [ ] Docs - [ ] Installation - [X] Performance and Scalability - [ ] Security - [X] User Experience - [ ] Test and Release - [ ] Developer Infrastructure - [ ] Client Plugin - [ ] Server Plugin - [ ] Extensions - [ ] Others
gitea-mirror 2026-05-05 13:41:27 -06:00
gitea-mirror commented 2026-05-05 13:41:30 -06:00
Author
Owner
Copy link

@Becods commented on GitHub (Jan 26, 2023):

login_fail_exit = false，frpc将会在与frps丢失连接之后等待frps再次可用并自动连接

<!-- gh-comment-id:1405277052 --> @Becods commented on GitHub (Jan 26, 2023): `login_fail_exit = false`，frpc将会在与frps丢失连接之后等待frps再次可用并自动连接
gitea-mirror commented 2026-05-05 13:41:30 -06:00
Author
Owner
Copy link

@suiahae commented on GitHub (Jan 27, 2023):

login_fail_exit = false，frpc将会在与frps丢失连接之后等待frps再次可用并自动连接

“frps再次可用”的确定，需要frpc向frps不停的发送请求吗？间隔时间呢

<!-- gh-comment-id:1406338848 --> @suiahae commented on GitHub (Jan 27, 2023): > `login_fail_exit = false`，frpc将会在与frps丢失连接之后等待frps再次可用并自动连接 “frps再次可用”的确定，需要frpc向frps不停的发送请求吗？间隔时间呢
gitea-mirror commented 2026-05-05 13:41:32 -06:00
Author
Owner
Copy link

@Becods commented on GitHub (Jan 28, 2023):

login_fail_exit = false，frpc将会在与frps丢失连接之后等待frps再次可用并自动连接

“frps再次可用”的确定，需要frpc向frps不停的发送请求吗？间隔时间呢

0eecab06c1/client/service.go (L135-L140)

<!-- gh-comment-id:1407302284 --> @Becods commented on GitHub (Jan 28, 2023): > > `login_fail_exit = false`，frpc将会在与frps丢失连接之后等待frps再次可用并自动连接 > > “frps再次可用”的确定，需要frpc向frps不停的发送请求吗？间隔时间呢 https://github.com/fatedier/frp/blob/0eecab06c17d69ba11a84162aae35ed7d94f0423/client/service.go#L135-L140
gitea-mirror commented 2026-05-05 13:41:32 -06:00
Author
Owner
Copy link

@suiahae commented on GitHub (Jan 28, 2023):

抱歉，是我没表达清楚。

某些情况下断连后，frpc会不断尝试连接frps，等待时间会从1s倍增至上限maxDelayTime（20s），此后会间隔maxDelayTime（20s）尝试 reconnect 。

我希望可以在配置文件中调整maxDelayTime，以免重连过于频繁。

2023/01/22 06:30:14 [I] [service.go:298] [*************] login to server success, get run id [*************], server udp port [0]
2023/01/22 06:30:14 [I] [proxy_manager.go:142] [*************] proxy added: [SSH]
2023/01/22 06:30:14 [I] [control.go:172] [*************] [SSH] start proxy success
2023/01/23 08:12:07 [I] [control.go:242] [*************] control writer is closing
2023/01/23 08:12:07 [I] [visitor_manager.go:60] [*************] gracefully shutdown visitor manager
2023/01/23 08:12:07 [I] [service.go:210] [*************] try to reconnect to server...
2023/01/23 08:12:17 [W] [service.go:213] [*************] reconnect to server error: dial tcp [***.***.***]:****: i/o timeout, wait 1s for another retry
2023/01/23 08:12:18 [I] [service.go:210] [*************] try to reconnect to server...
2023/01/23 08:12:28 [W] [service.go:213] [*************] reconnect to server error: dial tcp [***.***.***]:****: i/o timeout, wait 2s for another retry
2023/01/23 08:12:31 [I] [service.go:210] [*************] try to reconnect to server...
2023/01/23 08:12:41 [W] [service.go:213] [*************] reconnect to server error: dial tcp [***.***.***]:****: i/o timeout, wait 4s for another retry
2023/01/23 08:12:45 [I] [service.go:210] [*************] try to reconnect to server...
2023/01/23 08:12:55 [W] [service.go:213] [*************] reconnect to server error: dial tcp [***.***.***]:****: i/o timeout, wait 8s for another retry
2023/01/23 08:13:03 [I] [service.go:210] [*************] try to reconnect to server...
2023/01/23 08:13:13 [W] [service.go:213] [*************] reconnect to server error: dial tcp [***.***.***]:****: i/o timeout, wait 16s for another retry
2023/01/23 08:13:29 [I] [service.go:210] [*************] try to reconnect to server...
2023/01/23 08:13:39 [W] [service.go:213] [*************] reconnect to server error: dial tcp [***.***.***]:****: i/o timeout, wait 20s for another retry
2023/01/23 08:13:58 [I] [service.go:210] [*************] try to reconnect to server...
2023/01/23 08:14:08 [W] [service.go:213] [*************] reconnect to server error: dial tcp [***.***.***]:****: i/o timeout, wait 20s for another retry
...................
(13个小时)
...................
2023/01/26 21:13:29 [I] [service.go:210] [*************] try to reconnect to server...
2023/01/26 21:13:39 [W] [service.go:213] [*************] reconnect to server error: dial tcp [***.***.***]:****: i/o timeout, wait 20s for another retry
2023/01/26 21:13:58 [I] [service.go:210] [*************] try to reconnect to server...
2023/01/26 21:14:08 [W] [service.go:213] [*************] reconnect to server error: dial tcp [***.***.***]:****: i/o timeout, wait 20s for another retry
2023/01/26 21:14:27 [I] [service.go:210] [*************] try to reconnect to server...
2023/01/26 21:14:37 [W] [service.go:213] [*************] reconnect to server error: dial tcp [***.***.***]:****: i/o timeout, wait 20s for another retry
2023/01/26 21:14:56 [I] [service.go:210] [*************] try to reconnect to server...
2023/01/26 21:15:06 [W] [service.go:213] [*************] reconnect to server error: dial tcp [***.***.***]:****: i/o timeout, wait 20s for another retry
...................
<!-- gh-comment-id:1407310777 --> @suiahae commented on GitHub (Jan 28, 2023): 抱歉，是我没表达清楚。 某些情况下断连后，frpc会不断尝试连接frps，等待时间会从1s倍增至上限maxDelayTime（20s），此后会间隔maxDelayTime（20s）尝试 reconnect 。 我希望可以在配置文件中调整maxDelayTime，以免重连过于频繁。 ``` 2023/01/22 06:30:14 [I] [service.go:298] [*************] login to server success, get run id [*************], server udp port [0] 2023/01/22 06:30:14 [I] [proxy_manager.go:142] [*************] proxy added: [SSH] 2023/01/22 06:30:14 [I] [control.go:172] [*************] [SSH] start proxy success 2023/01/23 08:12:07 [I] [control.go:242] [*************] control writer is closing 2023/01/23 08:12:07 [I] [visitor_manager.go:60] [*************] gracefully shutdown visitor manager 2023/01/23 08:12:07 [I] [service.go:210] [*************] try to reconnect to server... 2023/01/23 08:12:17 [W] [service.go:213] [*************] reconnect to server error: dial tcp [***.***.***]:****: i/o timeout, wait 1s for another retry 2023/01/23 08:12:18 [I] [service.go:210] [*************] try to reconnect to server... 2023/01/23 08:12:28 [W] [service.go:213] [*************] reconnect to server error: dial tcp [***.***.***]:****: i/o timeout, wait 2s for another retry 2023/01/23 08:12:31 [I] [service.go:210] [*************] try to reconnect to server... 2023/01/23 08:12:41 [W] [service.go:213] [*************] reconnect to server error: dial tcp [***.***.***]:****: i/o timeout, wait 4s for another retry 2023/01/23 08:12:45 [I] [service.go:210] [*************] try to reconnect to server... 2023/01/23 08:12:55 [W] [service.go:213] [*************] reconnect to server error: dial tcp [***.***.***]:****: i/o timeout, wait 8s for another retry 2023/01/23 08:13:03 [I] [service.go:210] [*************] try to reconnect to server... 2023/01/23 08:13:13 [W] [service.go:213] [*************] reconnect to server error: dial tcp [***.***.***]:****: i/o timeout, wait 16s for another retry 2023/01/23 08:13:29 [I] [service.go:210] [*************] try to reconnect to server... 2023/01/23 08:13:39 [W] [service.go:213] [*************] reconnect to server error: dial tcp [***.***.***]:****: i/o timeout, wait 20s for another retry 2023/01/23 08:13:58 [I] [service.go:210] [*************] try to reconnect to server... 2023/01/23 08:14:08 [W] [service.go:213] [*************] reconnect to server error: dial tcp [***.***.***]:****: i/o timeout, wait 20s for another retry ................... (13个小时) ................... 2023/01/26 21:13:29 [I] [service.go:210] [*************] try to reconnect to server... 2023/01/26 21:13:39 [W] [service.go:213] [*************] reconnect to server error: dial tcp [***.***.***]:****: i/o timeout, wait 20s for another retry 2023/01/26 21:13:58 [I] [service.go:210] [*************] try to reconnect to server... 2023/01/26 21:14:08 [W] [service.go:213] [*************] reconnect to server error: dial tcp [***.***.***]:****: i/o timeout, wait 20s for another retry 2023/01/26 21:14:27 [I] [service.go:210] [*************] try to reconnect to server... 2023/01/26 21:14:37 [W] [service.go:213] [*************] reconnect to server error: dial tcp [***.***.***]:****: i/o timeout, wait 20s for another retry 2023/01/26 21:14:56 [I] [service.go:210] [*************] try to reconnect to server... 2023/01/26 21:15:06 [W] [service.go:213] [*************] reconnect to server error: dial tcp [***.***.***]:****: i/o timeout, wait 20s for another retry ................... ```
gitea-mirror commented 2026-05-05 13:41:33 -06:00
Author
Owner
Copy link

@fatedier commented on GitHub (Jan 29, 2023):

不倾向于暴露这个配置，你描述的场景 某些网络环境下，客户端与服务器间会出现长达数小时的断线，此时 20s 就显得有些短了。 和重试延迟没有太大的关系。重试本身没有什么成本，延迟会影响到恢复的时间，这个值不期望会被调整的很大。

<!-- gh-comment-id:1407685328 --> @fatedier commented on GitHub (Jan 29, 2023): 不倾向于暴露这个配置，你描述的场景 `某些网络环境下，客户端与服务器间会出现长达数小时的断线，此时 20s 就显得有些短了。` 和重试延迟没有太大的关系。重试本身没有什么成本，延迟会影响到恢复的时间，这个值不期望会被调整的很大。
gitea-mirror commented 2026-05-05 13:41:34 -06:00
Author
Owner
Copy link

@suiahae commented on GitHub (Jan 30, 2023):

不倾向于暴露这个配置，你描述的场景 某些网络环境下，客户端与服务器间会出现长达数小时的断线，此时 20s 就显得有些短了。 和重试延迟没有太大的关系。重试本身没有什么成本，延迟会影响到恢复的时间，这个值不期望会被调整的很大。

以20s的间隔重试，不会给fprc侧设备（CPU、内存、网口、路由器、交换机）带来性能和资源的压力吗？

如果这样，那这个功能确实没必要，我也能放心了

<!-- gh-comment-id:1408456057 --> @suiahae commented on GitHub (Jan 30, 2023): > 不倾向于暴露这个配置，你描述的场景 `某些网络环境下，客户端与服务器间会出现长达数小时的断线，此时 20s 就显得有些短了。` 和重试延迟没有太大的关系。重试本身没有什么成本，延迟会影响到恢复的时间，这个值不期望会被调整的很大。 以20s的间隔重试，不会给fprc侧设备（CPU、内存、网口、路由器、交换机）带来性能和资源的压力吗？ 如果这样，那这个功能确实没必要，我也能放心了
gitea-mirror commented 2026-05-05 13:41:34 -06:00
Author
Owner
Copy link

@xqzr commented on GitHub (Feb 4, 2023):

不倾向于暴露这个配置，你描述的场景 某些网络环境下，客户端与服务器间会出现长达数小时的断线，此时 20s 就显得有些短了。 和重试延迟没有太大的关系。重试本身没有什么成本，延迟会影响到恢复的时间，这个值不期望会被调整的很大。

以20s的间隔重试，不会给fprc侧设备（CPU、内存、网口、路由器、交换机）带来性能和资源的压力吗？

如果这样，那这个功能确实没必要，我也能放心了

就一个 TCP SYN 能有什么

<!-- gh-comment-id:1416805254 --> @xqzr commented on GitHub (Feb 4, 2023): > > 不倾向于暴露这个配置，你描述的场景 `某些网络环境下，客户端与服务器间会出现长达数小时的断线，此时 20s 就显得有些短了。` 和重试延迟没有太大的关系。重试本身没有什么成本，延迟会影响到恢复的时间，这个值不期望会被调整的很大。 > > 以20s的间隔重试，不会给fprc侧设备（CPU、内存、网口、路由器、交换机）带来性能和资源的压力吗？ > > 如果这样，那这个功能确实没必要，我也能放心了 就一个 TCP SYN ~~能有什么~~
gitea-mirror commented 2026-05-05 13:41:35 -06:00
Author
Owner
Copy link

@github-actions[bot] commented on GitHub (Mar 7, 2023):

Issues go stale after 30d of inactivity. Stale issues rot after an additional 7d of inactivity and eventually close.

<!-- gh-comment-id:1457279993 --> @github-actions[bot] commented on GitHub (Mar 7, 2023): Issues go stale after 30d of inactivity. Stale issues rot after an additional 7d of inactivity and eventually close.
gitea-mirror commented 2026-05-05 13:41:35 -06:00
Author
Owner
Copy link

@github-actions[bot] commented on GitHub (Mar 7, 2023):

Issues go stale after 30d of inactivity. Stale issues rot after an additional 7d of inactivity and eventually close.

<!-- gh-comment-id:1457280002 --> @github-actions[bot] commented on GitHub (Mar 7, 2023): Issues go stale after 30d of inactivity. Stale issues rot after an additional 7d of inactivity and eventually close.
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#2622
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?