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 #3778] login to server failed: session shutdown #3004

New issue
Closed
opened 2026-05-05 13:56:21 -06:00 by gitea-mirror · 19 comments
gitea-mirror commented 2026-05-05 13:56:21 -06:00
Owner
Copy link

Originally created by @qakcn on GitHub (Nov 16, 2023).
Original GitHub issue: https://github.com/fatedier/frp/issues/3778

Bug Description

刚从旧版本更新，服务器端正常启动，甚至旧版本客户端都可以正常连接到服务器端（见下方frps.log，其中id为63d08845171ca0f4的qakcn-nas相关条目就是还未更新版本的旧版客户端的连接。

但是从另一台更新到了新版客户端的机器上却无法连接。

请问问题可能出在哪里？该如何排查？

谢谢！

frpc Version

0.52.3

frps Version

0.52.3

System Architecture

linux/amd64

Configurations

frps.toml:

bindAddr="0.0.0.0"
bindPort = 7000
auth.token = "<token>"
log.to = "/var/log/frps/frps.log"
log.level = "trace"
allowPorts = [{start=22000, end=22999}]
detailedErrorsToClient = true

frpc.toml:

serverAddr="<server domin>"
serverPort=7000
log.to="/home/<user>/opt/frp/frpc.log"
log.level="debug"
auth.method="token"
auth.token="<token>"
user="ubuntu"
webServer.addr="0.0.0.0"
webServer.port=7400
webServer.user="<username>"
webServer.password="<password>"
includes= ["./conf.d/*.toml"]

conf.d/proxies.toml:

[[proxies]]
name = "ssh"
type = "stcp"
secretKey = "<secret key>"
localIP = "127.0.0.1"
localPort = 22
allowUsers=["*"]
transport.useEncryption = true
transport.useCompression = true

Logs

frps.log（receive heartbeat已删减）:

2023/11/16 17:13:55 [I] [root.go:102] frps uses config file: /opt/frp/frps.toml
2023/11/16 17:13:56 [I] [service.go:200] frps tcp listen on 0.0.0.0:7000
2023/11/16 17:13:56 [I] [root.go:111] frps started successfully
2023/11/16 17:13:57 [T] [service.go:455] start check TLS connection...
2023/11/16 17:13:57 [T] [service.go:464] check TLS connection success, isTLS: false custom: false
2023/11/16 17:13:57 [I] [service.go:533] [63d08845171ca0f4] client login info: ip [183.225.9.100:8907] version [0.46.0] hostname [] os [linux] arch [amd64]
2023/11/16 17:13:57 [I] [stcp.go:56] [63d08845171ca0f4] [qakcn-nas-qbittorrent] stcp proxy custom listen success
2023/11/16 17:13:57 [I] [control.go:500] [63d08845171ca0f4] new proxy [qakcn-nas-qbittorrent] type [stcp] success
2023/11/16 17:13:57 [D] [control.go:253] [63d08845171ca0f4] new work connection registered
2023/11/16 17:13:57 [I] [stcp.go:56] [63d08845171ca0f4] [qakcn-nas-aria2] stcp proxy custom listen success
2023/11/16 17:13:57 [I] [control.go:500] [63d08845171ca0f4] new proxy [qakcn-nas-aria2] type [stcp] success
2023/11/16 17:13:57 [I] [stcp.go:56] [63d08845171ca0f4] [qakcn-nas-aria2-json] stcp proxy custom listen success
2023/11/16 17:13:57 [I] [control.go:500] [63d08845171ca0f4] new proxy [qakcn-nas-aria2-json] type [stcp] success
2023/11/16 17:13:57 [I] [stcp.go:56] [63d08845171ca0f4] [qakcn-nas-yacht] stcp proxy custom listen success
2023/11/16 17:13:57 [I] [control.go:500] [63d08845171ca0f4] new proxy [qakcn-nas-router] type [stcp] success
2023/11/16 17:13:57 [I] [stcp.go:56] [63d08845171ca0f4] [qakcn-nas-ssh] stcp proxy custom listen success
2023/11/16 17:13:57 [I] [control.go:500] [63d08845171ca0f4] new proxy [qakcn-nas-ssh] type [stcp] success
2023/11/16 17:13:57 [I] [stcp.go:56] [63d08845171ca0f4] [qakcn-nas-omv] stcp proxy custom listen success
2023/11/16 17:13:57 [I] [control.go:500] [63d08845171ca0f4] new proxy [qakcn-nas-omv] type [stcp] success
2023/11/16 17:13:57 [I] [stcp.go:56] [63d08845171ca0f4] [qakcn-nas-transmission] stcp proxy custom listen success
2023/11/16 17:13:57 [I] [control.go:500] [63d08845171ca0f4] new proxy [qakcn-nas-transmission] type [stcp] success
2023/11/16 17:14:16 [T] [service.go:455] start check TLS connection...
2023/11/16 17:14:16 [T] [service.go:464] check TLS connection success, isTLS: true custom: false
2023/11/16 17:14:16 [D] [service.go:483] Accept new mux stream error: write tcp 172.26.83.161:7000->183.224.81.196:50706: write: connection reset by peer
...
2023/11/16 17:31:24 [T] [service.go:455] start check TLS connection...
2023/11/16 17:31:24 [T] [service.go:464] check TLS connection success, isTLS: true custom: false
2023/11/16 17:31:24 [D] [service.go:483] Accept new mux stream error: write tcp 172.26.83.161:7000->183.224.81.196:44036: write: connection reset by peer
...

frpc.log:

2023/11/16 17:31:24 [I] [root.go:139] start frpc service for config file [frpc.toml]
2023/11/16 17:31:24 [W] [service.go:131] login to server failed: session shutdown
2023/11/16 17:31:24 [I] [root.go:154] frpc service for config file [frpc.toml] stopped

Steps to reproduce

运行./frpc -c frpc.toml就出错。

Affected area

  • Docs
  • Installation
  • Performance and Scalability
  • Security
  • User Experience
  • Test and Release
  • Developer Infrastructure
  • Client Plugin
  • Server Plugin
  • Extensions
  • Others
Originally created by @qakcn on GitHub (Nov 16, 2023). Original GitHub issue: https://github.com/fatedier/frp/issues/3778 ### Bug Description 刚从旧版本更新，服务器端正常启动，甚至旧版本客户端都可以正常连接到服务器端（见下方`frps.log`，其中id为`63d08845171ca0f4`的`qakcn-nas`相关条目就是还未更新版本的旧版客户端的连接。 但是从另一台更新到了新版客户端的机器上却无法连接。 请问问题可能出在哪里？该如何排查？ 谢谢！ ### frpc Version 0.52.3 ### frps Version 0.52.3 ### System Architecture linux/amd64 ### Configurations `frps.toml`: ```Go bindAddr="0.0.0.0" bindPort = 7000 auth.token = "<token>" log.to = "/var/log/frps/frps.log" log.level = "trace" allowPorts = [{start=22000, end=22999}] detailedErrorsToClient = true ``` `frpc.toml`: ```Go serverAddr="<server domin>" serverPort=7000 log.to="/home/<user>/opt/frp/frpc.log" log.level="debug" auth.method="token" auth.token="<token>" user="ubuntu" webServer.addr="0.0.0.0" webServer.port=7400 webServer.user="<username>" webServer.password="<password>" includes= ["./conf.d/*.toml"] ``` `conf.d/proxies.toml`: ```Go [[proxies]] name = "ssh" type = "stcp" secretKey = "<secret key>" localIP = "127.0.0.1" localPort = 22 allowUsers=["*"] transport.useEncryption = true transport.useCompression = true ``` ### Logs `frps.log`（`receive heartbeat`已删减）: ``` 2023/11/16 17:13:55 [I] [root.go:102] frps uses config file: /opt/frp/frps.toml 2023/11/16 17:13:56 [I] [service.go:200] frps tcp listen on 0.0.0.0:7000 2023/11/16 17:13:56 [I] [root.go:111] frps started successfully 2023/11/16 17:13:57 [T] [service.go:455] start check TLS connection... 2023/11/16 17:13:57 [T] [service.go:464] check TLS connection success, isTLS: false custom: false 2023/11/16 17:13:57 [I] [service.go:533] [63d08845171ca0f4] client login info: ip [183.225.9.100:8907] version [0.46.0] hostname [] os [linux] arch [amd64] 2023/11/16 17:13:57 [I] [stcp.go:56] [63d08845171ca0f4] [qakcn-nas-qbittorrent] stcp proxy custom listen success 2023/11/16 17:13:57 [I] [control.go:500] [63d08845171ca0f4] new proxy [qakcn-nas-qbittorrent] type [stcp] success 2023/11/16 17:13:57 [D] [control.go:253] [63d08845171ca0f4] new work connection registered 2023/11/16 17:13:57 [I] [stcp.go:56] [63d08845171ca0f4] [qakcn-nas-aria2] stcp proxy custom listen success 2023/11/16 17:13:57 [I] [control.go:500] [63d08845171ca0f4] new proxy [qakcn-nas-aria2] type [stcp] success 2023/11/16 17:13:57 [I] [stcp.go:56] [63d08845171ca0f4] [qakcn-nas-aria2-json] stcp proxy custom listen success 2023/11/16 17:13:57 [I] [control.go:500] [63d08845171ca0f4] new proxy [qakcn-nas-aria2-json] type [stcp] success 2023/11/16 17:13:57 [I] [stcp.go:56] [63d08845171ca0f4] [qakcn-nas-yacht] stcp proxy custom listen success 2023/11/16 17:13:57 [I] [control.go:500] [63d08845171ca0f4] new proxy [qakcn-nas-router] type [stcp] success 2023/11/16 17:13:57 [I] [stcp.go:56] [63d08845171ca0f4] [qakcn-nas-ssh] stcp proxy custom listen success 2023/11/16 17:13:57 [I] [control.go:500] [63d08845171ca0f4] new proxy [qakcn-nas-ssh] type [stcp] success 2023/11/16 17:13:57 [I] [stcp.go:56] [63d08845171ca0f4] [qakcn-nas-omv] stcp proxy custom listen success 2023/11/16 17:13:57 [I] [control.go:500] [63d08845171ca0f4] new proxy [qakcn-nas-omv] type [stcp] success 2023/11/16 17:13:57 [I] [stcp.go:56] [63d08845171ca0f4] [qakcn-nas-transmission] stcp proxy custom listen success 2023/11/16 17:13:57 [I] [control.go:500] [63d08845171ca0f4] new proxy [qakcn-nas-transmission] type [stcp] success 2023/11/16 17:14:16 [T] [service.go:455] start check TLS connection... 2023/11/16 17:14:16 [T] [service.go:464] check TLS connection success, isTLS: true custom: false 2023/11/16 17:14:16 [D] [service.go:483] Accept new mux stream error: write tcp 172.26.83.161:7000->183.224.81.196:50706: write: connection reset by peer ... 2023/11/16 17:31:24 [T] [service.go:455] start check TLS connection... 2023/11/16 17:31:24 [T] [service.go:464] check TLS connection success, isTLS: true custom: false 2023/11/16 17:31:24 [D] [service.go:483] Accept new mux stream error: write tcp 172.26.83.161:7000->183.224.81.196:44036: write: connection reset by peer ... ``` `frpc.log`: ``` 2023/11/16 17:31:24 [I] [root.go:139] start frpc service for config file [frpc.toml] 2023/11/16 17:31:24 [W] [service.go:131] login to server failed: session shutdown 2023/11/16 17:31:24 [I] [root.go:154] frpc service for config file [frpc.toml] stopped ``` ### Steps to reproduce 运行`./frpc -c frpc.toml`就出错。 ### 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 13:56:21 -06:00
gitea-mirror commented 2026-05-05 13:56:25 -06:00
Author
Owner
Copy link

@qakcn commented on GitHub (Nov 16, 2023):

有时客户端日志会出现另一种错误：

2023/11/16 17:58:17 [I] [root.go:139] start frpc service for config file [frpc.toml]
2023/11/16 17:58:17 [W] [service.go:131] login to server failed: read tcp 192.168.3.134:46396->39.98.244.34:7000: read: connection reset by peer
2023/11/16 17:58:17 [I] [root.go:154] frpc service for config file [frpc.toml] stopped
<!-- gh-comment-id:1814125707 --> @qakcn commented on GitHub (Nov 16, 2023): 有时客户端日志会出现另一种错误： ``` 2023/11/16 17:58:17 [I] [root.go:139] start frpc service for config file [frpc.toml] 2023/11/16 17:58:17 [W] [service.go:131] login to server failed: read tcp 192.168.3.134:46396->39.98.244.34:7000: read: connection reset by peer 2023/11/16 17:58:17 [I] [root.go:154] frpc service for config file [frpc.toml] stopped ```
gitea-mirror commented 2026-05-05 13:56:26 -06:00
Author
Owner
Copy link

@qakcn commented on GitHub (Nov 16, 2023):

给服务器增加kcpBindPort和在客户端设置transport.protocol="kcp"之后可以使用。但是旧版本使用tcp协议没有问题，不知何解。

<!-- gh-comment-id:1814705861 --> @qakcn commented on GitHub (Nov 16, 2023): 给服务器增加`kcpBindPort`和在客户端设置`transport.protocol="kcp"`之后可以使用。但是旧版本使用tcp协议没有问题，不知何解。
gitea-mirror commented 2026-05-05 13:56:27 -06:00
Author
Owner
Copy link

@Markan325 commented on GitHub (Nov 17, 2023):

我也有同样问题，TCP搭配TLS也是报一样错误，设定TLS_Enable=false就又能连上了，不知道原因为何
同样TCP搭配TLS，退回0.50.0版又没问题了

<!-- gh-comment-id:1815633851 --> @Markan325 commented on GitHub (Nov 17, 2023): 我也有同样问题，TCP搭配TLS也是报一样错误，设定TLS_Enable=false就又能连上了，不知道原因为何 同样TCP搭配TLS，退回0.50.0版又没问题了
gitea-mirror commented 2026-05-05 13:56:28 -06:00
Author
Owner
Copy link

@superzjg commented on GitHub (Nov 17, 2023):

给服务器增加kcpBindPort和在客户端设置transport.protocol="kcp"之后可以使用。但是旧版本使用tcp协议没有问题，不知何解。

之前调试时也出现过类似情况，感觉是多次连接断开，导致7000端口没有来得及释放。此时换个端口号重启frps试试。

<!-- gh-comment-id:1815827118 --> @superzjg commented on GitHub (Nov 17, 2023): > 给服务器增加`kcpBindPort`和在客户端设置`transport.protocol="kcp"`之后可以使用。但是旧版本使用tcp协议没有问题，不知何解。 之前调试时也出现过类似情况，感觉是多次连接断开，导致7000端口没有来得及释放。此时换个端口号重启frps试试。
gitea-mirror commented 2026-05-05 13:56:29 -06:00
Author
Owner
Copy link

@qakcn commented on GitHub (Nov 17, 2023):

给服务器增加kcpBindPort和在客户端设置transport.protocol="kcp"之后可以使用。但是旧版本使用tcp协议没有问题，不知何解。

之前调试时也出现过类似情况，感觉是多次连接断开，导致7000端口没有来得及释放。此时换个端口号重启frps试试。

应该不是。前面说了，旧版客户端可以连上新版服务器，新版客户端就连不上，所以端口应该没有问题。

<!-- gh-comment-id:1815841764 --> @qakcn commented on GitHub (Nov 17, 2023): > > 给服务器增加`kcpBindPort`和在客户端设置`transport.protocol="kcp"`之后可以使用。但是旧版本使用tcp协议没有问题，不知何解。 > > 之前调试时也出现过类似情况，感觉是多次连接断开，导致7000端口没有来得及释放。此时换个端口号重启frps试试。 应该不是。前面说了，旧版客户端可以连上新版服务器，新版客户端就连不上，所以端口应该没有问题。
gitea-mirror commented 2026-05-05 13:56:29 -06:00
Author
Owner
Copy link

@superzjg commented on GitHub (Nov 17, 2023):

给服务器增加kcpBindPort和在客户端设置transport.protocol="kcp"之后可以使用。但是旧版本使用tcp协议没有问题，不知何解。

之前调试时也出现过类似情况，感觉是多次连接断开，导致7000端口没有来得及释放。此时换个端口号重启frps试试。

应该不是。前面说了，旧版客户端可以连上新版服务器，新版客户端就连不上，所以端口应该没有问题。

依据经验，还有一个情况，就是你frps设置的https端口与默认绑定端口号相同，但是没有设置transport.tls.disableCustomTLSFirstByte = false
启用 TLS 连接时，不发送 0x17 特殊字节。默认为 true。当配置为 true 时，无法和 vhostHTTPSPort 端口复用。

<!-- gh-comment-id:1815853091 --> @superzjg commented on GitHub (Nov 17, 2023): > > > 给服务器增加`kcpBindPort`和在客户端设置`transport.protocol="kcp"`之后可以使用。但是旧版本使用tcp协议没有问题，不知何解。 > > > > > > 之前调试时也出现过类似情况，感觉是多次连接断开，导致7000端口没有来得及释放。此时换个端口号重启frps试试。 > > 应该不是。前面说了，旧版客户端可以连上新版服务器，新版客户端就连不上，所以端口应该没有问题。 依据经验，还有一个情况，就是你frps设置的https端口与默认绑定端口号相同，但是没有设置`transport.tls.disableCustomTLSFirstByte = false` 启用 TLS 连接时，不发送 0x17 特殊字节。默认为 true。当配置为 true 时，无法和 vhostHTTPSPort 端口复用。
gitea-mirror commented 2026-05-05 13:56:30 -06:00
Author
Owner
Copy link

@qakcn commented on GitHub (Nov 17, 2023):

给服务器增加kcpBindPort和在客户端设置transport.protocol="kcp"之后可以使用。但是旧版本使用tcp协议没有问题，不知何解。

之前调试时也出现过类似情况，感觉是多次连接断开，导致7000端口没有来得及释放。此时换个端口号重启frps试试。

应该不是。前面说了，旧版客户端可以连上新版服务器，新版客户端就连不上，所以端口应该没有问题。

依据经验，还有一个情况，就是你frps设置的https端口与默认绑定端口号相同，但是没有设置transport.tls.disableCustomTLSFirstByte = false 启用 TLS 连接时，不发送 0x17 特殊字节。默认为 true。当配置为 true 时，无法和 vhostHTTPSPort 端口复用。

我的配置文件在上面贴出来了，没有其他设置。这个服务器也没有http或是https等服务。因为是买的国内服务器没有备案，现在是完全当作内网穿透服务器来用的。目前只用了stcp这一种类型。

话说你这我倒是怀疑，是不是默认TLS导致服务商那边当作HTTPS流量了，但是旧版就没问题，旧版的TLS有所不同吗？我试试。 实践证明并不行。

我现在倒是可以勉强KCP用一用，但是毕竟现在的运营商都不太喜欢UDP流量，可以的话我还是想搞明白问题在哪儿。新版的客户端和旧版的到底哪里配置不同。

<!-- gh-comment-id:1815857382 --> @qakcn commented on GitHub (Nov 17, 2023): > > > > 给服务器增加`kcpBindPort`和在客户端设置`transport.protocol="kcp"`之后可以使用。但是旧版本使用tcp协议没有问题，不知何解。 > > > > > > > > > 之前调试时也出现过类似情况，感觉是多次连接断开，导致7000端口没有来得及释放。此时换个端口号重启frps试试。 > > > > > > 应该不是。前面说了，旧版客户端可以连上新版服务器，新版客户端就连不上，所以端口应该没有问题。 > > 依据经验，还有一个情况，就是你frps设置的https端口与默认绑定端口号相同，但是没有设置`transport.tls.disableCustomTLSFirstByte = false` 启用 TLS 连接时，不发送 0x17 特殊字节。默认为 true。当配置为 true 时，无法和 vhostHTTPSPort 端口复用。 我的配置文件在上面贴出来了，没有其他设置。这个服务器也没有http或是https等服务。因为是买的国内服务器没有备案，现在是完全当作内网穿透服务器来用的。目前只用了stcp这一种类型。 ~~话说你这我倒是怀疑，是不是默认TLS导致服务商那边当作HTTPS流量了，但是旧版就没问题，旧版的TLS有所不同吗？我试试。~~ 实践证明并不行。 我现在倒是可以勉强KCP用一用，但是毕竟现在的运营商都不太喜欢UDP流量，可以的话我还是想搞明白问题在哪儿。新版的客户端和旧版的到底哪里配置不同。
gitea-mirror commented 2026-05-05 13:56:31 -06:00
Author
Owner
Copy link

@superzjg commented on GitHub (Nov 17, 2023):

我测试过quic比kcp快，也是udp的
TLS是在v0.50.0改成了默认true的。

目前我路由器上服务器，当设置了https 端口和绑定端口一样，而frpc没有设置 transport.tls.disableCustomTLSFirstByte = false。frpc就会复现 session shutdown 错误。改前者或后者都可以消除。其他情况没有见到。

<!-- gh-comment-id:1815885947 --> @superzjg commented on GitHub (Nov 17, 2023): 我测试过quic比kcp快，也是udp的 TLS是在v0.50.0改成了默认true的。 目前我路由器上服务器，当设置了https 端口和绑定端口一样，而frpc没有设置 transport.tls.disableCustomTLSFirstByte = false。frpc就会复现 session shutdown 错误。改前者或后者都可以消除。其他情况没有见到。
gitea-mirror commented 2026-05-05 13:56:32 -06:00
Author
Owner
Copy link

@qakcn commented on GitHub (Nov 17, 2023):

我测试过quic比kcp快，也是udp的 TLS是在v0.50.0改成了默认true的。

目前我路由器上服务器，当设置了https 端口和绑定端口一样，而frpc没有设置 transport.tls.disableCustomTLSFirstByte = false。frpc就会复现 session shutdown 错误。改前者或后者都可以消除。其他情况没有见到。

看来确实是TLS的问题，禁用了之后就好了。不知道是不是服务器没有配置TLS证书的原因。

软件层面没有任何相关日志，要不是看了你和上面那位朋友 @Markan325 的说明，完全不知道是这方面的问题。谢谢你们的帮助。

希望作者能在日志层面对TLS错误有所体现吧。

<!-- gh-comment-id:1815909363 --> @qakcn commented on GitHub (Nov 17, 2023): > 我测试过quic比kcp快，也是udp的 TLS是在v0.50.0改成了默认true的。 > > 目前我路由器上服务器，当设置了https 端口和绑定端口一样，而frpc没有设置 transport.tls.disableCustomTLSFirstByte = false。frpc就会复现 session shutdown 错误。改前者或后者都可以消除。其他情况没有见到。 看来确实是TLS的问题，禁用了之后就好了。不知道是不是服务器没有配置TLS证书的原因。 软件层面没有任何相关日志，要不是看了你和上面那位朋友 @Markan325 的说明，完全不知道是这方面的问题。谢谢你们的帮助。 希望作者能在日志层面对TLS错误有所体现吧。
gitea-mirror commented 2026-05-05 13:56:33 -06:00
Author
Owner
Copy link

@superzjg commented on GitHub (Nov 17, 2023):

我测试过quic比kcp快，也是udp的 TLS是在v0.50.0改成了默认true的。
目前我路由器上服务器，当设置了https 端口和绑定端口一样，而frpc没有设置 transport.tls.disableCustomTLSFirstByte = false。frpc就会复现 session shutdown 错误。改前者或后者都可以消除。其他情况没有见到。

看来确实是TLS的问题，禁用了之后就好了。不知道是不是服务器没有配置TLS证书的原因。

软件层面没有任何相关日志，要不是看了你和上面那位朋友 @Markan325 的说明，完全不知道是这方面的问题。谢谢你们的帮助。

希望作者能在日志层面对TLS错误有所体现吧。

好吧，可能是某种特定情况下有bug。
禁用TLS也没关系，反正你是用 stcp 模式，配合frpc在每个代理上配置一个 transport.useEncryption = true也是很安全的。

<!-- gh-comment-id:1815919434 --> @superzjg commented on GitHub (Nov 17, 2023): > > 我测试过quic比kcp快，也是udp的 TLS是在v0.50.0改成了默认true的。 > > 目前我路由器上服务器，当设置了https 端口和绑定端口一样，而frpc没有设置 transport.tls.disableCustomTLSFirstByte = false。frpc就会复现 session shutdown 错误。改前者或后者都可以消除。其他情况没有见到。 > > 看来确实是TLS的问题，禁用了之后就好了。不知道是不是服务器没有配置TLS证书的原因。 > > 软件层面没有任何相关日志，要不是看了你和上面那位朋友 @Markan325 的说明，完全不知道是这方面的问题。谢谢你们的帮助。 > > 希望作者能在日志层面对TLS错误有所体现吧。 好吧，可能是某种特定情况下有bug。 禁用TLS也没关系，反正你是用 stcp 模式，配合frpc在每个代理上配置一个 `transport.useEncryption = true`也是很安全的。
gitea-mirror commented 2026-05-05 13:56:33 -06:00
Author
Owner
Copy link

@qakcn commented on GitHub (Nov 17, 2023):

我测试过quic比kcp快，也是udp的 TLS是在v0.50.0改成了默认true的。
目前我路由器上服务器，当设置了https 端口和绑定端口一样，而frpc没有设置 transport.tls.disableCustomTLSFirstByte = false。frpc就会复现 session shutdown 错误。改前者或后者都可以消除。其他情况没有见到。

看来确实是TLS的问题，禁用了之后就好了。不知道是不是服务器没有配置TLS证书的原因。
软件层面没有任何相关日志，要不是看了你和上面那位朋友 @Markan325 的说明，完全不知道是这方面的问题。谢谢你们的帮助。
希望作者能在日志层面对TLS错误有所体现吧。

好吧，可能是某种特定情况下有bug。 禁用TLS也没关系，反正你是用 stcp 模式，配合frpc在每个代理上配置一个 transport.useEncryption = true也是很安全的。

应该不是bug，可能是TLS需要配置证书。但是在日志里完全看不出是TLS的问题，这是需要改进的地方。

此issue暂时不关闭吧，希望作者能看到。

最后再次谢谢诸位以及作者！

<!-- gh-comment-id:1816389703 --> @qakcn commented on GitHub (Nov 17, 2023): > > > 我测试过quic比kcp快，也是udp的 TLS是在v0.50.0改成了默认true的。 > > > 目前我路由器上服务器，当设置了https 端口和绑定端口一样，而frpc没有设置 transport.tls.disableCustomTLSFirstByte = false。frpc就会复现 session shutdown 错误。改前者或后者都可以消除。其他情况没有见到。 > > > > > > 看来确实是TLS的问题，禁用了之后就好了。不知道是不是服务器没有配置TLS证书的原因。 > > 软件层面没有任何相关日志，要不是看了你和上面那位朋友 @Markan325 的说明，完全不知道是这方面的问题。谢谢你们的帮助。 > > 希望作者能在日志层面对TLS错误有所体现吧。 > > 好吧，可能是某种特定情况下有bug。 禁用TLS也没关系，反正你是用 stcp 模式，配合frpc在每个代理上配置一个 `transport.useEncryption = true`也是很安全的。 应该不是bug，可能是TLS需要配置证书。但是在日志里完全看不出是TLS的问题，这是需要改进的地方。 此issue暂时不关闭吧，希望作者能看到。 最后再次谢谢诸位以及作者！
gitea-mirror commented 2026-05-05 13:56:34 -06:00
Author
Owner
Copy link

@xqzr commented on GitHub (Nov 17, 2023):

域名未备案 被 RST。
尝试 serverAddr="<server IP>" 或者 transport.protocol="quic" 526e809bd5/conf/frps_full_example.toml (L15)

<!-- gh-comment-id:1817034440 --> @xqzr commented on GitHub (Nov 17, 2023): 域名未备案 被 RST。 尝试 `serverAddr="<server IP>"` 或者 `transport.protocol="quic"` https://github.com/fatedier/frp/blob/526e809bd50eed4ff5c2211adc91126abb864530/conf/frps_full_example.toml#L15
gitea-mirror commented 2026-05-05 13:56:34 -06:00
Author
Owner
Copy link

@github-actions[bot] commented on GitHub (Dec 18, 2023):

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

<!-- gh-comment-id:1859350139 --> @github-actions[bot] commented on GitHub (Dec 18, 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:56:35 -06:00
Author
Owner
Copy link

@liaorongjian commented on GitHub (May 23, 2024):

这个问题，你们解决了

<!-- gh-comment-id:2126154008 --> @liaorongjian commented on GitHub (May 23, 2024): 这个问题，你们解决了
gitea-mirror commented 2026-05-05 13:56:35 -06:00
Author
Owner
Copy link

@1434537427 commented on GitHub (May 25, 2024):

我的情况是这样的：
镜像版本：frpc 0.57.0、同一份配置文件；
过程：在极空间正常运行1个月左右后，突然无法正常启动，报[login to server failed: session shutdown]；
测试：在Docker Desktop中启动正常，也能正常代理并访问；
处理：极空间系统版本升级到V1.0.0410090，然后“系统设置”中重启docker服务，就能正常启动frpc，并代理访问了；我推测是“重启docker服务”起的作用，遇到的同学可以先试试。
image

<!-- gh-comment-id:2130673552 --> @1434537427 commented on GitHub (May 25, 2024): 我的情况是这样的： 镜像版本：frpc 0.57.0、同一份配置文件； 过程：在极空间正常运行1个月左右后，突然无法正常启动，报[login to server failed: session shutdown]； 测试：在Docker Desktop中启动正常，也能正常代理并访问； 处理：极空间系统版本升级到V1.0.0410090，然后“系统设置”中重启docker服务，就能正常启动frpc，并代理访问了；我推测是“重启docker服务”起的作用，遇到的同学可以先试试。 ![image](https://github.com/fatedier/frp/assets/116991753/63af662c-bd5f-479d-9a4e-cd924938792a)
gitea-mirror commented 2026-05-05 13:56:36 -06:00
Author
Owner
Copy link

@Fatalerr commented on GitHub (Jun 3, 2025):

域名未备案 被 RST。 尝试 serverAddr="<server IP>" 或者 transport.protocol="quic"

感谢！ 我的问题通过将serverAddr的域名改为ip地址后解决。

<!-- gh-comment-id:2933491110 --> @Fatalerr commented on GitHub (Jun 3, 2025): > 域名未备案 被 RST。 尝试 `serverAddr="<server IP>"` 或者 `transport.protocol="quic"` > 感谢！ 我的问题通过将serverAddr的域名改为ip地址后解决。
gitea-mirror commented 2026-05-05 13:56:36 -06:00
Author
Owner
Copy link

@gigberg commented on GitHub (Jun 16, 2025):

de690a55c8/conf/frpc_full_example.toml (L100-L102)

just add transport.tls.enable = true to your frpc.toml configuration, if your frp client's version superior to v0.50.0

<!-- gh-comment-id:2975507377 --> @gigberg commented on GitHub (Jun 16, 2025): https://github.com/fatedier/frp/blob/de690a55c81a222003564a569e6e2d943c859445/conf/frpc_full_example.toml#L100-L102 just add `transport.tls.enable = true` to your frpc.toml configuration, if your frp client's version superior to v0.50.0
gitea-mirror commented 2026-05-05 13:56:36 -06:00
Author
Owner
Copy link

@RockNHawk commented on GitHub (Oct 28, 2025):

transport.tls.enable = false
this works for me

<!-- gh-comment-id:3456867290 --> @RockNHawk commented on GitHub (Oct 28, 2025): transport.tls.enable = false this works for me
gitea-mirror commented 2026-05-05 13:56:37 -06:00
Author
Owner
Copy link

@Raiscies commented on GitHub (Dec 2, 2025):

transport.tls.serverName = " "
将sni置为一个空格可行. 如果将serverName直接置为空串会导致frp客户端默认发送serverAddr的域名. 实际上任意(已备案或暂时不在黑名单上)的串都能绕过RST, 例如baidu.com. 但x.com测试不行.
另外目前不知道在sni填入任意非域名的串是否会导致在未来继续被RST, 这个有待测试.
另外这个逻辑是不是应该改一改呢? 也许将serverName=""的逻辑更改为在TLS握手时不发送SNI更加合适?

<!-- gh-comment-id:3602278990 --> @Raiscies commented on GitHub (Dec 2, 2025): `transport.tls.serverName = " "` 将sni置为一个空格可行. 如果将serverName直接置为空串会导致frp客户端默认发送serverAddr的域名. 实际上任意(已备案或暂时不在黑名单上)的串都能绕过RST, 例如baidu.com. 但x.com测试不行. 另外目前不知道在sni填入任意非域名的串是否会导致在未来继续被RST, 这个有待测试. 另外这个逻辑是不是应该改一改呢? 也许将serverName=""的逻辑更改为在TLS握手时不发送SNI更加合适?
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#3004
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?