[GH-ISSUE #5079] 更新了0.65.0之后，频繁出现404

gitea-mirror commented

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

Owner

Originally created by @maxin9966 on GitHub (Nov 28, 2025).
Original GitHub issue: https://github.com/fatedier/frp/issues/5079

Bug Description

之前服务端是0.5x.x，客户端是0.49.0，用了很久，没有太大问题，但是遇到长连接数超过一定数量的就会出现404导致服务崩溃，必须手动重启frps才能解决。

然后我更新到0.65.0，现在非常频繁的出现404，哪怕极低负载也会频繁出现404，一会好一会404，间歇性的。

两个版本更新前后用的配置还是有区别的，之前用的ini，后面改成toml，配置项我已经不记得之前是怎么写的了。

以下是新的配置。

frpc Version

0.65.0

frps Version

0.65.0

System Architecture

linux/amd64

Configurations

frps:

# frps.toml - 正确配置
bindAddr = "0.0.0.0"
bindPort = 5443
kcpBindPort = 5443
vhostHTTPPort = 7860

# 核心调整：将此参数设为12分钟（720秒），解决HTTP请求排队问题
vhostHTTPTimeout = 720

# 连接保活设置：恢复合理值，确保连接通道的健康
transport.heartbeatTimeout = 90        # 恢复为默认的90秒或稍大值（如120秒）
transport.tcpKeepalive = 7200           # 保持默认的2小时，不要修改

# 连接池与多路复用设置（您的现有配置很好，继续保持）
transport.maxPoolCount = 100
transport.tcpMux = true
transport.tcpMuxKeepaliveInterval = 60  # 60秒是很好的设置

auth.method = "token"
auth.token = "8ad3d13x429..."

webServer.addr = "0.0.0.0"
webServer.port = 9527
webServer.user = "admin"
webServer.password = "test..."

allowPorts = [
    { start = 1024, end = 65535 }
]

log.to = "console"
log.level = "info"

frpc:

# ========================
# 基础服务端连接配置
# ========================
serverAddr = "hk.77chat.cn"
serverPort = 5443

# 身份认证 (必须与服务端一致)
auth.method = "token"
auth.token = "8adfdfd..."

# ========================
# 客户端全局优化配置
# ========================
# 1. 防崩溃机制：登录失败不退出，持续重试
loginFailExit = false

# 2. 传输层优化
[transport]
heartbeatTimeout = 90  # 与服务端同步，维持连接活性
tcpMux = true          # 启用多路复用，提升性能
tls.enable = false

# 3. 日志配置
#[log]
#to = "./frpc.log"
#level = "info"
#maxDays = 3

# ========================
# 代理配置 (Services/Proxies)
# ========================

Logs

No response

Steps to reproduce

...

Affected area

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

Originally created by @maxin9966 on GitHub (Nov 28, 2025). Original GitHub issue: https://github.com/fatedier/frp/issues/5079 ### Bug Description 之前服务端是0.5x.x，客户端是0.49.0，用了很久，没有太大问题，但是遇到长连接数超过一定数量的就会出现404导致服务崩溃，必须手动重启frps才能解决。然后我更新到0.65.0，现在非常频繁的出现404，哪怕极低负载也会频繁出现404，一会好一会404，间歇性的。两个版本更新前后用的配置还是有区别的，之前用的ini，后面改成toml，配置项我已经不记得之前是怎么写的了。以下是新的配置。 ### frpc Version 0.65.0 ### frps Version 0.65.0 ### System Architecture linux/amd64 ### Configurations ## frps: ``` # frps.toml - 正确配置 bindAddr = "0.0.0.0" bindPort = 5443 kcpBindPort = 5443 vhostHTTPPort = 7860 # 核心调整：将此参数设为12分钟（720秒），解决HTTP请求排队问题 vhostHTTPTimeout = 720 # 连接保活设置：恢复合理值，确保连接通道的健康 transport.heartbeatTimeout = 90 # 恢复为默认的90秒或稍大值（如120秒） transport.tcpKeepalive = 7200 # 保持默认的2小时，不要修改 # 连接池与多路复用设置（您的现有配置很好，继续保持） transport.maxPoolCount = 100 transport.tcpMux = true transport.tcpMuxKeepaliveInterval = 60 # 60秒是很好的设置 auth.method = "token" auth.token = "8ad3d13x429..." webServer.addr = "0.0.0.0" webServer.port = 9527 webServer.user = "admin" webServer.password = "test..." allowPorts = [ { start = 1024, end = 65535 } ] log.to = "console" log.level = "info" ``` ## frpc: ``` # ======================== # 基础服务端连接配置 # ======================== serverAddr = "hk.77chat.cn" serverPort = 5443 # 身份认证 (必须与服务端一致) auth.method = "token" auth.token = "8adfdfd..." # ======================== # 客户端全局优化配置 # ======================== # 1. 防崩溃机制：登录失败不退出，持续重试 loginFailExit = false # 2. 传输层优化 [transport] heartbeatTimeout = 90 # 与服务端同步，维持连接活性 tcpMux = true # 启用多路复用，提升性能 tls.enable = false # 3. 日志配置 #[log] #to = "./frpc.log" #level = "info" #maxDays = 3 # ======================== # 代理配置 (Services/Proxies) # ======================== ``` ### Logs _No response_ ### Steps to reproduce 1. 2. 3. ... ### Affected area - [ ] Docs - [ ] Installation - [ ] Performance and Scalability - [ ] Security - [ ] User Experience - [ ] Test and Release - [ ] Developer Infrastructure - [ ] Client Plugin - [ ] Server Plugin - [ ] Extensions - [ ] Others

gitea-mirror

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

closed this issue
added the
lifecycle/stale
label

gitea-mirror commented

2026-05-05 14:32:16 -06:00

Author

Owner

@github-actions[bot] commented on GitHub (Dec 13, 2025):

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

@github-actions[bot] commented on GitHub (Dec 13, 2025): Issues go stale after 14d of inactivity. Stale issues rot after an additional 3d of inactivity and eventually close.