[GH-ISSUE #1698] Can not disable tcp_mux #1343

New issue

Closed

opened 2026-05-05 12:51:14 -06:00 by gitea-mirror · 2 comments

gitea-mirror commented

2026-05-05 12:51:14 -06:00

Owner

Originally created by @NemoAlex on GitHub (Mar 12, 2020).
Original GitHub issue: https://github.com/fatedier/frp/issues/1698

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 将会直接关闭。)
(请不要在 issue 评论中出现无意义的加1，我也是 等内容，将会被直接删除。)
(由于个人精力有限，和系统环境，网络环境等相关的求助问题请转至其他论坛或社交平台。)

Use the commands below to provide key information from your environment:
You do NOT have to include this information if this is a FEATURE REQUEST

What version of frp are you using (./frpc -v or ./frps -v)?
0.32.0 both c and s

What operating system and processor architecture are you using (go env)?
frps: Linux amd64
frpc: darwin

Configures you used:
frps:

[common]
bind_port = 83
token = xxx
dashboard_port = 7502
dashboard_user = xxx
dashboard_pwd = xxx
authentication_timeout = 3600
log_file = console
tcp_mux = false

[plugin.port-manager]
addr = 127.0.0.1:3003
path = /handler
ops = NewProxy

frpc:

[common]
server_addr = xxx
server_port = 83
token = xxx
tcp_mux = false

[ssh]
type = tcp
local_ip = 127.0.0.1
local_port = 3000
remote_port = 6088

Steps to reproduce the issue:

Run frps on Linux
Run frpc on Mac
Boom

Describe the results you received:

2020/03/12 14:25:43 [W] [service.go:101] login to server failed: EOF
EOF

Describe the results you expected:

Additional information you deem important (e.g. issue happens only occasionally):

Can you point out what caused this issue (optional)
It works when I turn on tcp_mux on client.
So maybe the tcp_mux option on server is not effected?

Originally created by @NemoAlex on GitHub (Mar 12, 2020). Original GitHub issue: https://github.com/fatedier/frp/issues/1698 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 将会直接关闭。) (请不要在 issue 评论中出现无意义的 **加1**，**我也是** 等内容，将会被直接删除。) (由于个人精力有限，和系统环境，网络环境等相关的求助问题请转至其他论坛或社交平台。) Use the commands below to provide key information from your environment: You do NOT have to include this information if this is a FEATURE REQUEST **What version of frp are you using (./frpc -v or ./frps -v)?** 0.32.0 both c and s **What operating system and processor architecture are you using (`go env`)?** frps: Linux amd64 frpc: darwin **Configures you used:** frps: ``` [common] bind_port = 83 token = xxx dashboard_port = 7502 dashboard_user = xxx dashboard_pwd = xxx authentication_timeout = 3600 log_file = console tcp_mux = false [plugin.port-manager] addr = 127.0.0.1:3003 path = /handler ops = NewProxy ``` frpc: ``` [common] server_addr = xxx server_port = 83 token = xxx tcp_mux = false [ssh] type = tcp local_ip = 127.0.0.1 local_port = 3000 remote_port = 6088 ``` **Steps to reproduce the issue:** 1. Run frps on Linux 2. Run frpc on Mac 3. Boom **Describe the results you received:** ``` 2020/03/12 14:25:43 [W] [service.go:101] login to server failed: EOF EOF ``` **Describe the results you expected:** **Additional information you deem important (e.g. issue happens only occasionally):** **Can you point out what caused this issue (optional)** It works when I turn on tcp_mux on client. So maybe the tcp_mux option on server is not effected?

gitea-mirror closed this issue

2026-05-05 12:51:15 -06:00

gitea-mirror commented

2026-05-05 12:51:17 -06:00

Author

Owner

@fatedier commented on GitHub (Mar 12, 2020):

Can't reproduce this issue in my environment. Make sure you start your frpc and frps with -c option to specify the configure file.

@fatedier commented on GitHub (Mar 12, 2020): Can't reproduce this issue in my environment. Make sure you start your frpc and frps with `-c` option to specify the configure file.

gitea-mirror commented

2026-05-05 12:51:18 -06:00

Author

Owner

@NemoAlex commented on GitHub (Mar 13, 2020):

Turns out you are right.
I messed up arguments on node.js child_process.

@NemoAlex commented on GitHub (Mar 13, 2020): Turns out you are right. I messed up arguments on node.js child_process.