RPRX
既然已经有了明确的只针对 `x_padding` 的封锁，下个版本顺便加个自定义吧，此外既然这个 CDN 已经关注 XHTTP 了，建议换一家 重申对抗 CDN 检测的思路：不要一次把手里的牌打完。比如说如果 XHTTP 早就加了 `x_padding` 自定义，CDN 就会检测其它方面。
我试了一下要加较为完美的自定义的话得加至少六个选项（双端长度，双端名称，双端候选字符），还没算上是否放 Referrer 什么的 我觉得，或许，还是允许禁用 x_padding 吧，不过这样会导致 req/resp header 长度较为固定，除非保证和 body 粘包，我再想想吧
~~之前我都开始改了结果发现这选项加不完所以就又删了，既然有人愿意接盘就加个 PR welcome 吧~~
如果要处理 ICMP 则只改一个 WireGuard 入站不够，还要 VLESS 代理协议能处理 ICMP 本来想着用 0 代表 TUN 数据，但是反向代理的下一步设计又想把 0 定义为“无意义”，我再想想吧。。。
> 这可不止往协议定义里加一个ip或者icmp payload的事 其实我在想按端口为 0 的 UDP 来处理也行
因为都是允许丢包，目前 Xray-core 中 UDP 端口 0 是没有定义的，然后那些特殊域名（Mux 等）应当是端口为 0 的 TCP
只剩个小问题就是除了 ICMP 是否还有代理其它 IP 包的需求，如果是的话则不应只考虑 ICMP
比如可以服务端检测一下 UDP 端口为 0 时包内不允许出现 TCP 和 UDP 的代号，其它的都放行
TUN 入站肯定是要有的，现在只是只考虑 ICMP 还是同时也考虑其它包的问题，~~感觉考虑其它包的话有点类似于真的组网了~~ ~~Reopen 是作为 reminder，不重要所以不一定什么时候实现~~
感谢 PR，新的 JS 没有可读性，原本的文件留一下吧，新文件可以命名为 dialer_new.html 之类的，~~否则你消失了的话可能难以维护~~