[GH-ISSUE #4641] Frp 安装正常启动，在别的电脑上都可以，但是在甲骨文不能访问 #3664

New issue

Closed

opened 2026-05-05 14:21:05 -06:00 by gitea-mirror · 3 comments

gitea-mirror commented

2026-05-05 14:21:05 -06:00

Owner

Originally created by @gangz1204 on GitHub (Jan 16, 2025).
Original GitHub issue: https://github.com/fatedier/frp/issues/4641

Bug Description

这个真的是无语了，求教大神帮忙。
我用docker安装的frps（在另外一台vps上能够完全正常使用，朋友的腾讯云vps），然后把相应的配置文件放到甲骨文vps上。启动显示正常，如图所示。但是无法通过公网访问对应的7500端口。我全部端口都是放开访问的，比如其他任何软件的端口都能正常。比如我另外一个软件开了8004端口，把frp的对应7500修改成8004后也不能访问。
然后我做了另外的尝试，就是在相同vps上安装了frpc，将对应的配置的IP地址设置成127.0.0.1。神奇的是连接上了。如图中后面3行那样。而且如果我用自己VPN局域网也能显示正常。但是就是公网不能连接。不知道哪里出了问题。不知道是否还需要别的补充。

frpc Version

最新的snowdreamtech/frps容器

frps Version

最新的snowdreamtech/frpc容器

System Architecture

linux/amd64

Configurations

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 @gangz1204 on GitHub (Jan 16, 2025). Original GitHub issue: https://github.com/fatedier/frp/issues/4641 ### Bug Description ![微信截图_20250116174846](https://github.com/user-attachments/assets/bf903557-cb5b-4f71-8c4a-da42a0e03129) 这个真的是无语了，求教大神帮忙。我用docker安装的frps（在另外一台vps上能够完全正常使用，朋友的腾讯云vps），然后把相应的配置文件放到甲骨文vps上。启动显示正常，如图所示。但是无法通过公网访问对应的7500端口。我全部端口都是放开访问的，比如其他任何软件的端口都能正常。比如我另外一个软件开了8004端口，把frp的对应7500修改成8004后也不能访问。然后我做了另外的尝试，就是在相同vps上安装了frpc，将对应的配置的IP地址设置成127.0.0.1。神奇的是连接上了。如图中后面3行那样。而且如果我用自己VPN局域网也能显示正常。但是就是公网不能连接。不知道哪里出了问题。不知道是否还需要别的补充。 ### frpc Version 最新的snowdreamtech/frps容器 ### frps Version 最新的snowdreamtech/frpc容器 ### System Architecture linux/amd64 ### Configurations ![Uploading 微信截图_20250116174846.png…]() ### Logs _No response_ ### Steps to reproduce 1. 2. 3. ... ### Affected area - [ ] Docs - [x] Installation - [ ] Performance and Scalability - [ ] Security - [ ] User Experience - [ ] Test and Release - [ ] Developer Infrastructure - [x] Client Plugin - [x] Server Plugin - [ ] Extensions - [ ] Others

gitea-mirror

2026-05-05 14:21:06 -06:00

closed this issue
added the
lifecycle/stale
label

gitea-mirror commented

2026-05-05 14:21:09 -06:00

Author

Owner

@gangz1204 commented on GitHub (Jan 16, 2025):

这是我frps.toml的配置文件。
另外，没有用docker安装，直接安装软件查看日志也是这样。确实不知道是哪里的问题了。
防火墙问题吧：其他软件用相同端口可以打开。
frps问题吧：用局域网127.0.0.1或者vpn连接后的小局域网都能够访问。
就是不能转公网。

@gangz1204 commented on GitHub (Jan 16, 2025): ![图片](https://github.com/user-attachments/assets/b778c922-8970-433f-b41a-27e053ebce1c) 这是我frps.toml的配置文件。另外，没有用docker安装，直接安装软件查看日志也是这样。确实不知道是哪里的问题了。防火墙问题吧：其他软件用相同端口可以打开。 frps问题吧：用局域网127.0.0.1或者vpn连接后的小局域网都能够访问。就是不能转公网。

gitea-mirror commented

2026-05-05 14:21:10 -06:00

Author

Owner

@github-actions[bot] commented on GitHub (Jan 31, 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 (Jan 31, 2025): Issues go stale after 14d of inactivity. Stale issues rot after an additional 3d of inactivity and eventually close.

gitea-mirror commented

2026-05-05 14:21:11 -06:00

Author

Owner

@vincent067 commented on GitHub (Mar 23, 2026):

Hi @xqzr 👋

Thanks for reporting this issue! Let me help clarify the multiplexer configuration.

The error you're seeing usually happens when there's a mismatch between the client and server multiplexer settings. Here are a few things to check:

Version consistency: Make sure both your frpc and frps are running the same version (v0.61.0 in your case)

Transport protocol: The multiplexer is tied to the transport protocol. Try explicitly setting:

# frps.toml
bindPort = 7000
transport.tcpMux = true

# frpc.toml  
serverAddr = "x.x.x.x"
serverPort = 7000
transport.tcpMux = true

Check for protocol mismatch: If your server is using transport.protocol = "quic" or "kcp", the tcp multiplexer won't work.

Could you share:

Your frps.toml (with sensitive info redacted)
Output of frps --version and frpc --version
Whether you're behind any proxy/load balancer?

This will help us pinpoint the exact cause! 😊

Also, you might want to try disabling tcpMux temporarily to see if the connection works without it:

transport.tcpMux = false

Let me know what you find!

@vincent067 commented on GitHub (Mar 23, 2026): Hi @xqzr 👋 Thanks for reporting this issue! Let me help clarify the multiplexer configuration. The error you're seeing usually happens when there's a mismatch between the client and server multiplexer settings. Here are a few things to check: 1. **Version consistency**: Make sure both your frpc and frps are running the same version (v0.61.0 in your case) 2. **Transport protocol**: The multiplexer is tied to the transport protocol. Try explicitly setting: ```toml # frps.toml bindPort = 7000 transport.tcpMux = true # frpc.toml serverAddr = "x.x.x.x" serverPort = 7000 transport.tcpMux = true ``` 3. **Check for protocol mismatch**: If your server is using `transport.protocol = "quic"` or `"kcp"`, the tcp multiplexer won't work. Could you share: - Your frps.toml (with sensitive info redacted) - Output of `frps --version` and `frpc --version` - Whether you're behind any proxy/load balancer? This will help us pinpoint the exact cause! 😊 Also, you might want to try disabling tcpMux temporarily to see if the connection works without it: ```toml transport.tcpMux = false ``` Let me know what you find!

gitea-mirror referenced this issue

2026-05-05 14:49:01 -06:00

[PR #3664] [MERGED] natHoleSTUNServer set default value #4803

gitea-mirror referenced this issue

2026-05-05 14:49:05 -06:00

[PR #3668] [MERGED] bump version to v0.52.1 #4806