什么时候出一个proxy protocol v2支持。我没有本地公网地址，就租用了带有ipv4公网地址的vps，但是用frp转发后，发现127.0.0.1得了MVP！严重影响反吸血效果！如图所示：
proxy protocol v2也不难实现吧，不过就是在tcp连接的开头加了段二进制消息头指明tcp的真实来源地址而已
资料：
proxy protocol v1 / v2 详细介绍
（这篇文章你得挂全局梯子访问）frp官方文档 - 获取客户端真实ip地址
相比起支持扩展协议头 我目前正在研究一种替代frp的方案
主要是为解决流量在通过应用层转发后 源ip丢失的问题
其可以适用于任何客户端
目前在在实验阶段已经取得了成功
其核心 就是通过iptable或者nftables对流量进行处理
当然这样就不能使用frp来转发了
只能使用虚拟网卡和隧道
这里使用的 gost 来实现的
这个软件不仅集成了 隧道功能还集成了代理功能
我们正需要代理来解决 向tracker汇报时候的对外IP问题
其实如果一个项目附带了代理的话，非常容易被gfw gank
走ssh代理很容易被限速（gfw对全加密流量格外严格）
如果真的要通过代理连接peer，专业的事就应该交给专业的工具（比如xray项目）
如果你建过airport，应该能明白这些
如果不太理解gfw的工作机制，建议阅读此文章：gfw工作原理解析（2两年的文章，已过时但仍有参考价值）
不过我仍然对你的项目抱有期望，开源项目为爱发电较为艰难，但是仍然祝你好运！ 
vps在国外？目前这个方案默认服务器是在国内的
不过这个问题也需要考虑
gost 倒是内置Shadowsocks支持
也许外部再套一层加密 就可以了
实现应该不难，主要我猜测可能有性能问题，本来说c语言能直接调用系统api去处理tcp协议层，这么做要集成frp在软件内部持续不间断抓包流量，分析出协议头来识别，要获取frp后的真实ip有一定性能影响吧，再加上frp是单核心cpu工作的软件，等实现成功可能宽带吞吐量缩水成200M宽带，本来直接调用系统是能跑3000M宽带的，楼上说的隧道层可能是更好的解决方案
proxy protocol v2只是一种可能的方案：
对于bitcomet来说，只需要在收到tcp连接时读一次开头那部分的字节解析就行。proxy protocol v2仅仅在tcp connected后，在最开头发送几字节的源地址信息头而已，并不需要持续解析（只要这个tcp没断），也不需要集成frp。
引用来自官网的话：
Proxy Protocol功能启用后，frpc 在和本地服务建立连接后，会先发送一段Proxy Protocol的协议内容给本地服务，本地服务通过解析这一内容可以获得访问用户的真实 IP。所以不仅仅是 HTTP 服务，任何的 TCP 服务，只要支持这一协议，都可以获得用户的真实 IP 地址。
另外：并不是说要集成frp，只是单纯在bitcomet的设置中提供这么一个选项就行，比如【为来自以下ip的tcp连接启用proxy protocol v2】，不仅仅是frp在使用此协议，还有众多反代使用此协议。
隧道方案最大的问题是不支持windows（除非写驱动）。而frp和xray等外部组件提供windows版本，或者其它开源项目可以自己手动改代码编译
此问题已被解决
TUN 适配器可以选择Wintun
而TAP适配器选择 openvpn的 TAP 适配器即可
WinTUN 已被广泛的使用
抱歉，是我孤陋寡闻了，立马写程序在frp与wintun中构建中间件
另外，我大胆推测一下：
当一个用户尝试用vps转发流量时，它的技术水平很可能已经不容小觑了，TA能自己做更多事情。
或许多兼容一个已经广泛存在的协议可以给软件带来更多的可拓展性和生机。
（性能的话，只是读取tcp连接开头内容，又不是读取每个tcp封包的内容，我严重怀疑性能比牵动多层系统调用的tun或者iptable好）
@zhuxiaoying85309
proxy protocol v2仅在tcp连接开头发送固定格式的数据
从我浅陋的汇编知识上来看，系统调用过调用门从ring3升级到ring0，开销大概率比为tcp连接开头解析固定格式的二进制数据要大。
而且iptables需要root权限，wintun要装驱动（我记得是这样的），会多出一些权限问题
微软C语言开发者文档里面，翻了好一会没查到相关的函数调用方式，等于说没办法调用系统api
网上检索frp获取真实ip协议都指向为haproxy的源码，文中也提到了有性能问题，只能做到尽可能减少影响
https://www.haproxy.org/download/2.0/doc/proxy-protocol.txt
等于说要加载个 libproxy.h 库文件去处理这些tcp流量数据，要做高级选项的话记得考虑到utp打洞ip地址传递之类不要冲突了
需要一个内存缓冲区来记录所有接收到的tcp流量，然后分析是不是头，然后在取头的值，在没有分析流量之前你并不知道这个包里面的内容是什么
找到用户列表相关联的peer，然后对peer重写ip地址，或者标注为127.0.0.1[注册用户][真实ip]
我看了一下，frp没有支持udp
如果只是针对tcp则协议本身并不难（有公网了为什么还要utp）
既然已经说了作为选项提供，那么很有必要来一个【为以下ip启用proxy protocol v2解析】，增加安全性（防止外来连接恶意发送proxy protocol v2头伪造地址）的同时能加快解析速度。如果头解析失败则直接丢弃即可，因为你已经【为以下ip启用proxy protocol v2解析】，说明来自此ip的应该全为转发流量（很多时候来自127.0.0.1）
这样一来，限定死来源地址，无需解析包具体是什么。ip命中了就解析tcp头，解析失败了就丢弃（当然日志里得警告一手，方便配置时调试）
而且这一段附加头的长度固定，固定解析即可，ip匹配上了丢这一段给库拿结果即可，如图所示：
不过要多维持一张表来记录信息是真的，但性能开销大概率比wintun和iptables之类的方案更小，且操作起来更加名正言顺一点（应用层能解决得很好的东西闹到更底层的地方总感觉不太好）
@zhuxiaoying85309
而且很重要的一点是：proxy protocol v2压根没和tun类方案冲突吧！
proxy protocol v2做了是让软件的可拓展性和兼容性更好，tun则提供了一种用户能自己动手丰衣足食的方案（虽然说开销好像大了点，毕竟虚拟了一堆东西）
小孩子才做选择，我全都要！
wintun和iptables有点技术就能自己搞定，但是兼容proxy protocol v2则只能由bitcomet开发组来做了（毕竟没开源）。希望能对此协议做出兼容（proxy protocol v2又不是frp独有的！还有很多别的项目使用呢！）
Beta5已发布，欢迎试用
已处理，现在不会请求了
是无管理员权限的用户在使用中遇到问题了吗？由于彗星的配置文件是存在本用户名下的 %APPDATA%\BitComet\ 目录里，如果让无管理员权限的用户请求以管理员权限启动，则启动后访问的配置文件目录是管理员账户的，而不是当前普通用户的。所以目前需要提权的操作，都是点击按钮后重新启动一个提权进程来处理的。
是种子文件制作好后，做种用户的任务进度只有60%？不明白【种子完成度】是啥意思，最好截个图
不同版本的操作系统支持度不一致，可能需要精细化处理了
看了一下，支持proxy protocol v2似乎并不困难。
1、增加一个设置界面，指定启用proxy protocol v2协议的代理服务器IP地址。
2、对来自此代理服务器的BT连接，强制识别并处理proxy protocol v2协议，得到peer的实际IP和端口。
真要做的话，需要搭建测试环境。方便的话，最好能提供你正在使用的相关代理服务器配置信息。
】：
那按照道理来讲 在运行需要提权的操作时应该会弹出请求提权的提示？
不过现在遇到的问题就是 请求提权操作后没有任何反映
也许单个操作提权出现了问题？
不同平台对emoji的显示不一样 这个其实不是什么大问题
重要的是在配置文件中的文件名要和实际的文件名相同
即使系统或程序不能正确的显示emoji 其实也是不影响的使用的
现在的问题是 配置文件中总是将emoji转换为下划线
但是在实际创建文件的时候依然使用emoji字符
这就导致一遇到带有emoji字符的文件就会出现找不到文件的问题
因为在配置文件中记录的是转译后的文件名
但实际的文件名依然是原始的带emoji的文件
所以目前最简单解决方法 就是在创建文件的时候也对emoji字符进行转译
还有utp传输时CPU占用率高的原因找到了吗？
我记得浏览器会在404的情况下强制请求favicon.ico 不过试了下beta5确实没请求了
https://www.haproxy.org/download/2.0/doc/proxy-protocol.txt 文档底部有个示例调用库代码可以参考，frp就是这篇文章教程了
Linux centos vps服务器中安装frp内网穿透软件为比特彗星BT种子下载提供公网IP绿灯开放端口
记得给处理的用户打个标注，，比如说这种样子二选一
127.0.0.1[注册用户][真实ip]
真实ip[注册用户][proxy-protocol]
Windows版已经改好了，文件名可以保留emoji字符了，下个版本发布。macOS、Linux版本wchar_t是4字节的，本身就支持emoji。
我没遇到，能够显示UAC提示框
之前profiling过，部分原因是小数据包拼接效率不高。还没时间好好优化
我是在页面head里加了一行 <link rel = "icon" href = "data:,"> 就不会请求了
1個讚
也许是因为关闭了UAC提示？
看来还需要再测试一下
不知道局域网下断流是否也是这个问题造成的
utp目前即使在局域网下也不能正常工作
速度非常缓慢 在接通后一段时间便会断开 再过一段时间后再次连接
这样循环往复
webui菜单的弹出模式已经由悬停改为了和GUI相同的按下
webui上的通行证登录功能已经可以使用了
不过如果登录失败的话 目前还不能显示设备原因
只能在GUI中查看
也许可以再webui状态栏中 的账户状态中显示错误原因
目前似乎只会显示未登录和登录后的邮箱名
beta6已发布，欢迎试用
增加了一个气泡提示，对监听端口设置项生效条件进行了说明
已支持
已添加登录错误提示信息
1個讚