本帖最后由 逆天域 于 2020-2-15 17:55 编辑
原理
在开MC服务器时,若使用frp,我们通常会使用tcp映射,也就是frpc.ini中的:
复制代码在frp原github的readme中明确给出,使用frp时,返回真实ip的方式有两种,分别是HTTP X-Forwarded-For与Proxy Protocol。
而前者只适用于HTTP映射,后者则支持全tcp映射
原readme中是这么给出的:
frp 支持通过 Proxy Protocol 协议来传递经过 frp 代理的请求的真实 IP,此功能支持所有以 TCP 为底层协议的类型,不支持 UDP。
Proxy Protocol 功能启用后,frpc 在和本地服务建立连接后,会先发送一段 Proxy Protocol 的协议内容给本地服务,本地服务通过解析这一内容可以获得访问用户的真实 IP。所以不仅仅是 HTTP 服务,任何的 TCP 服务,只要支持这一协议,都可以获得用户的真实 IP 地址。
需要注意的是,在代理配置中如果要启用此功能,需要本地的服务能够支持 Proxy Protocol 这一协议,目前 nginx 和 haproxy 都能够很好的支持。
事实上,作者还是十分贴心的加入了Proxy Protocol这一功能,BungeeCord可以很好的接受Proxy Protocol的包
在BungeeCord的config.yml中,我们可以在listeners下看到:
复制代码而我们只需要把false改为true就可以很完美的让BungeeCord接收Proxy Protocol的包。
而最后剩下的就仅仅是让frpc启用这项发送Proxy Protocol包的功能,根据原Readme中所说:
这里以 https 类型为例:
复制代码只需要在代理配置中增加一行 proxy_protocol_version = v2 即可开启此功能。
那么如果你的端口是25565,你的MC服务器映射应该是这样的:
复制代码至此,BungeeCord配合frpc的Proxy Protocol就可以做到完美的返回玩家真实的IP到服务器上。
这里不一定非要是BungeeCord,只要支持Proxy Protocol的代理都是可以的~

本文为逆天域Intary原创文章,已同步发布至CSDN博客,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接和本声明。
CSDN文章链接:https://blog.csdn.net/qq_34922260/article/details/103338881
原理
在开MC服务器时,若使用frp,我们通常会使用tcp映射,也就是frpc.ini中的:
- type = tcp
而前者只适用于HTTP映射,后者则支持全tcp映射
原readme中是这么给出的:
frp 支持通过 Proxy Protocol 协议来传递经过 frp 代理的请求的真实 IP,此功能支持所有以 TCP 为底层协议的类型,不支持 UDP。
Proxy Protocol 功能启用后,frpc 在和本地服务建立连接后,会先发送一段 Proxy Protocol 的协议内容给本地服务,本地服务通过解析这一内容可以获得访问用户的真实 IP。所以不仅仅是 HTTP 服务,任何的 TCP 服务,只要支持这一协议,都可以获得用户的真实 IP 地址。
需要注意的是,在代理配置中如果要启用此功能,需要本地的服务能够支持 Proxy Protocol 这一协议,目前 nginx 和 haproxy 都能够很好的支持。
事实上,作者还是十分贴心的加入了Proxy Protocol这一功能,BungeeCord可以很好的接受Proxy Protocol的包
在BungeeCord的config.yml中,我们可以在listeners下看到:
- listeners:
- proxy_protocol: false
而最后剩下的就仅仅是让frpc启用这项发送Proxy Protocol包的功能,根据原Readme中所说:
这里以 https 类型为例:
- # frpc.ini
- [web]
- type = https
- local_port = 443
- custom_domains = test.yourdomain.com
- # 目前支持 v1 和 v2 两个版本的 proxy protocol 协议。
- proxy_protocol_version = v2
那么如果你的端口是25565,你的MC服务器映射应该是这样的:
- # frpc.ini
- [mcserver]
- type = tcp
- local_port = 25565
- proxy_protocol_version = v2
这里不一定非要是BungeeCord,只要支持Proxy Protocol的代理都是可以的~

本文为逆天域Intary原创文章,已同步发布至CSDN博客,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接和本声明。
CSDN文章链接:https://blog.csdn.net/qq_34922260/article/details/103338881
楼主有了解过spigot下哪些插件能解析Proxy Protocol吗?
SkyCatcher 发表于 2019-12-3 15:49
楼主有了解过spigot下哪些插件能解析Proxy Protocol吗?
抱歉,我还没有去了解单服接收proxy protocol包的方法,不过套一层bungeecord再将默认服务器设一下我觉得效果是一样的

逆天域 发表于 2019-12-3 20:08
抱歉,我还没有去了解单服接收proxy protocol包的方法,不过套一层bungeecord再将默认服务器设一下我觉得 ...
效果应该差不多,但是多一层端会损耗一些性能,同时也增加了复杂度
我试了下这个方案,有个很大的问题是 proxy_protocol: true 以后,如果直接连接bungeecord,就连不进去了。而只能识别通过proxy protocol后的流量
SkyCatcher 发表于 2019-12-14 19:51
我试了下这个方案,有个很大的问题是 proxy_protocol: true 以后,如果直接连接bungeecord,就连不进去了。 ...
是这样的 因为这改变了bungeecord接收的包的模式 目前可能只有两种接包模式分别建立bc了 暂时还没有想到其他解决方案
逆天域 发表于 2019-12-15 22:01
是这样的 因为这改变了bungeecord接收的包的模式 目前可能只有两种接包模式分别建立bc了 暂时还没有想到 ...
但是分别建立BC的话,两个BC后面的数据可能会不互通吧
SkyCatcher 发表于 2019-12-15 22:35
但是分别建立BC的话,两个BC后面的数据可能会不互通吧
emm 还没试过 毕竟套两层BC的开服很少有人去做 毕竟平常情况下不会有太多的需求 而且也会导致很多麻烦的事情~
感谢作者分享
逆天域 发表于 2019-12-21 12:30
emm 还没试过 毕竟套两层BC的开服很少有人去做 毕竟平常情况下不会有太多的需求 而且也会导致很多麻烦的 ...
在本地BC前再套一层frp,frp占用cpu应该不多吧
@SkyCatcher
DustSettles 发表于 2020-2-27 06:22
在本地BC前再套一层frp,frp占用cpu应该不多吧
@SkyCatcher
方案是可行的,但是实在是很麻烦,相当于为了加一条线路,在本地开了个bc端,又在加速节点开了个bc端。网络结构越复杂,出现故障的概率就越大
11111111111111111111111111
66666666666666666666