github-starred/frp

Fork 0

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

[GH-ISSUE #2724] write message to control connection error: stream closed #2177

New issue

Closed

opened 2026-05-05 13:24:05 -06:00 by gitea-mirror · 4 comments

gitea-mirror commented

2026-05-05 13:24:05 -06:00

Owner

Originally created by @rucciva on GitHub (Dec 30, 2021).
Original GitHub issue: https://github.com/fatedier/frp/issues/2724

Bug Description

frpc on a particular machine keep terminating with write message to control connection error: stream closed error. Meanwhile it doesn't happen on frpc on other machine (different network). Could it be related to NAT settings or network security?

frpc Version

v0.38.0

frps Version

v0.38.0

System Architecture

linux/amd64

Configurations

frps

docker-compose.yml

version: "3.7"
services:
  frps:
    image: fatedier/frps:v0.38.0
    network_mode: host
    restart: always
    volumes:
      - ./frps.ini:/app/frps.ini

frps.ini

[common]
log_level = trace

bind_port = 7000
bind_udp_port = 7001
kcp_bind_port = 7000

vhost_http_port=80
vhost_https_port=443

frpc

docker-compose.yml

version: "3.7"
services:
  frpc:
    image: fatedier/frpc:v0.38.0
    network_mode: host
    restart: always
    volumes:
      - ./frpc.ini:/app/frpc.ini

frpc.ini

[common]
server_addr = redacted
server_port = 7000
protocol = tcp
log_level = trace

[caddy-203]
type = tcp
local_port = 443
local_ip = 127.0.0.1
remote_port = 54443
proxy_protocol_version = v2

Logs

frps

frps_1  | 2021/12/30 08:23:59 [I] [root.go:202] frps uses command line arguments for config
frps_1  | 2021/12/30 08:23:59 [I] [service.go:192] frps tcp listen on 0.0.0.0:7000
frps_1  | 2021/12/30 08:23:59 [I] [root.go:209] frps started successfully
frps_1  | 2021/12/30 08:24:02 [I] [service.go:447] [eb0da52437ec3964] client login info: ip [redacted:44026] version [0.38.0] hostname [] os [linux] arch [amd64]
frps_1  | 2021/12/30 08:24:32 [I] [control.go:307] [eb0da52437ec3964] control writer is closing
frps_1  | 2021/12/30 08:24:32 [I] [control.go:382] [eb0da52437ec3964] client exit success
frps_1  | 2021/12/30 08:24:32 [I] [service.go:447] [eb0da52437ec3964] client login info: ip [redacted:54273] version [0.38.0] hostname [] os [linux] arch [amd64]

frpc

frpc_1  | 2021/12/30 08:24:32 [I] [service.go:301] [eb0da52437ec3964] login to server success, get run id [eb0da52437ec3964], server udp port [0]
frpc_1  | 2021/12/30 08:24:32 [I] [proxy_manager.go:144] [eb0da52437ec3964] proxy added: [caddy-203]
frpc_1  | 2021/12/30 08:24:32 [T] [proxy_wrapper.go:171] [eb0da52437ec3964] [caddy-203] change status from [new] to [wait start]
frpc_1  | 2021/12/30 08:24:32 [D] [control.go:265] [eb0da52437ec3964] read from control connection EOF
frpc_1  | 2021/12/30 08:24:32 [W] [control.go:294] [eb0da52437ec3964] write message to control connection error: stream closed
frpc_1  | 2021/12/30 08:24:32 [I] [service.go:174] [eb0da52437ec3964] try to reconnect to server...
frpc_1  | 2021/12/30 08:24:32 [I] [visitor_manager.go:60] [eb0da52437ec3964] gracefully shutdown visitor manager

Steps to reproduce

start frps
start frpc
wait for a few minute and connection will be terminated
...

Affected area

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

Originally created by @rucciva on GitHub (Dec 30, 2021). Original GitHub issue: https://github.com/fatedier/frp/issues/2724 ### Bug Description frpc on a particular machine keep terminating with `write message to control connection error: stream closed` error. Meanwhile it doesn't happen on frpc on other machine (different network). Could it be related to NAT settings or network security? ### frpc Version v0.38.0 ### frps Version v0.38.0 ### System Architecture linux/amd64 ### Configurations #### frps ##### docker-compose.yml ``` version: "3.7" services: frps: image: fatedier/frps:v0.38.0 network_mode: host restart: always volumes: - ./frps.ini:/app/frps.ini ``` ##### frps.ini ```ini [common] log_level = trace bind_port = 7000 bind_udp_port = 7001 kcp_bind_port = 7000 vhost_http_port=80 vhost_https_port=443 ``` #### frpc ##### docker-compose.yml ``` version: "3.7" services: frpc: image: fatedier/frpc:v0.38.0 network_mode: host restart: always volumes: - ./frpc.ini:/app/frpc.ini ``` ##### frpc.ini ```ini [common] server_addr = redacted server_port = 7000 protocol = tcp log_level = trace [caddy-203] type = tcp local_port = 443 local_ip = 127.0.0.1 remote_port = 54443 proxy_protocol_version = v2 ``` ### Logs #### frps ``` frps_1 | 2021/12/30 08:23:59 [I] [root.go:202] frps uses command line arguments for config frps_1 | 2021/12/30 08:23:59 [I] [service.go:192] frps tcp listen on 0.0.0.0:7000 frps_1 | 2021/12/30 08:23:59 [I] [root.go:209] frps started successfully frps_1 | 2021/12/30 08:24:02 [I] [service.go:447] [eb0da52437ec3964] client login info: ip [redacted:44026] version [0.38.0] hostname [] os [linux] arch [amd64] frps_1 | 2021/12/30 08:24:32 [I] [control.go:307] [eb0da52437ec3964] control writer is closing frps_1 | 2021/12/30 08:24:32 [I] [control.go:382] [eb0da52437ec3964] client exit success frps_1 | 2021/12/30 08:24:32 [I] [service.go:447] [eb0da52437ec3964] client login info: ip [redacted:54273] version [0.38.0] hostname [] os [linux] arch [amd64] ``` #### frpc ``` frpc_1 | 2021/12/30 08:24:32 [I] [service.go:301] [eb0da52437ec3964] login to server success, get run id [eb0da52437ec3964], server udp port [0] frpc_1 | 2021/12/30 08:24:32 [I] [proxy_manager.go:144] [eb0da52437ec3964] proxy added: [caddy-203] frpc_1 | 2021/12/30 08:24:32 [T] [proxy_wrapper.go:171] [eb0da52437ec3964] [caddy-203] change status from [new] to [wait start] frpc_1 | 2021/12/30 08:24:32 [D] [control.go:265] [eb0da52437ec3964] read from control connection EOF frpc_1 | 2021/12/30 08:24:32 [W] [control.go:294] [eb0da52437ec3964] write message to control connection error: stream closed frpc_1 | 2021/12/30 08:24:32 [I] [service.go:174] [eb0da52437ec3964] try to reconnect to server... frpc_1 | 2021/12/30 08:24:32 [I] [visitor_manager.go:60] [eb0da52437ec3964] gracefully shutdown visitor manager ``` ### Steps to reproduce 1. start frps 2. start frpc 3. wait for a few minute and connection will be terminated ... ### 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:24:05 -06:00

closed this issue
added the
lifecycle/stale
label

gitea-mirror commented

2026-05-05 13:24:08 -06:00

Author

Owner

@fatedier commented on GitHub (Jan 4, 2022):

Could it be related to NAT settings or network security?

Most probability yes.

@fatedier commented on GitHub (Jan 4, 2022): > Could it be related to NAT settings or network security? Most probability yes.

gitea-mirror commented

2026-05-05 13:24:09 -06:00

Author

Owner

@kum1ko commented on GitHub (Jan 6, 2022):

@fatedier 同样地问题（同样的系统），反复测试过，已排除防火墙等基本问题

简述下环境：
A服务器，visitor，类型tcp，通过stcp访问C服务器的代理服务（不涉及gfw）
B服务器，frps
C服务器，frpc，代理服务提供者，类型tcp

AC服务器均链接至B服务器，C使用tcp连接。

复现流程

A服务器上启动一个docker容器，并通过设置env的方式配置http*_proxy，希望在容器内部访问C的代理服务。
复现问题，日志如同@rucciva 一致，此时客户端（A）和服务端（B）均有日志显示，说明AB连接正常。
将容器的代理地址设为C服务器上代理的公网地址，不出现错误。
将容器的代理地址设为其他代理地址，不出现错误。
本地PC上的Chrome通过流程1中A服务器visitor的代理访问C的服务，不出现错误。
保持流程1的环境，将visitor的连接类型改为kcp，不出现错误。

综上问题的结论是：这个docker中的应用访问tcp类型的stcp服务时，frpc报错。更换这个结论中的任意变量均不会出现错误。

@kum1ko commented on GitHub (Jan 6, 2022): @fatedier 同样地问题（同样的系统），反复测试过，已排除防火墙等基本问题 **简述下环境：** A服务器，visitor，类型tcp，通过stcp访问C服务器的代理服务（不涉及gfw） B服务器，frps C服务器，frpc，代理服务提供者，类型tcp AC服务器均链接至B服务器，C使用tcp连接。 **复现流程** 1. A服务器上启动一个docker容器，并通过设置env的方式配置http*_proxy，希望在容器内部访问C的代理服务。 2. 复现问题，日志如同@rucciva 一致，此时客户端（A）和服务端（B）均有日志显示，说明AB连接正常。 3. 将容器的代理地址设为C服务器上代理的公网地址，不出现错误。 4. 将容器的代理地址设为其他代理地址，不出现错误。 5. 本地PC上的Chrome通过流程1中A服务器visitor的代理访问C的服务，不出现错误。 5. 保持流程1的环境，将visitor的连接类型改为kcp，不出现错误。综上问题的结论是：这个docker中的应用访问tcp类型的stcp服务时，frpc报错。更换这个结论中的任意变量均不会出现错误。

gitea-mirror commented

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

Author

Owner

@fatedier commented on GitHub (Jan 6, 2022):

@kum1ko Your problem maybe not the same with this issue although with same log.

Can you open another issue?

@fatedier commented on GitHub (Jan 6, 2022): @kum1ko Your problem maybe not the same with this issue although with same log. Can you open another issue?

gitea-mirror commented

2026-05-05 13:24:11 -06:00

Author

Owner

@github-actions[bot] commented on GitHub (Feb 6, 2022):

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

@github-actions[bot] commented on GitHub (Feb 6, 2022): Issues go stale after 30d of inactivity. Stale issues rot after an additional 7d of inactivity and eventually close.