[Feature request]: 两天时间使用新版获取不了IP，解决后依旧没网，哎。
npzs opened this issue · comments
Related Problem / 相关问题
第一个建议：使用warp v 的时候，要是能先同步一下间隔版本的更新日志就好了。像最新的3.0改动较大建议重装，我是处问题了上这里才看到，在不知情的情况下直接升级了脚本，导致我知道应该重装的时候，用新版卸载旧版，也不知道这样是不是有问题，这给我后来的排查埋下隐患，总觉得是不是老版本没卸载对，所以后面的问题解决不了的时候，还去找了老版本又卸载一次。
第二个建议：我看最新版使用了wireguard-go，是为了使用保留字段Reserved，但毕竟三方实现不如内核的效率和稳定，为什么不通过脚本自动检测IP的地理位置或者让用户手动选择内核呢？这个保留字段是不是只有HK和LA地区的主机才需要？那样的话让所有地区的脚本用户迁就这两个地区，有点舍本逐末的赶脚。
第三个建议：就因为这个Reserved ，我活活整了两天，因为老版本没有，更新日志和说明也没写到底从哪获取，我看issuse里也有人问，但作者都没回复^_^，我查了好多资料，终于找到个方法：
安装warp-go，导出singbox配置，会自动有这个Reserved ，还有人说注册官方客户端，在配置文件里有（然而并没有）。singbox那个好用，但这并不是最简单的方法，最简单的就是menu脚本，最初安装或者升级账户的时候，选择提供token（可以由作者提供的网址或者team主页开F12查看），token有时效需要快点复制，然后脚本竟然会……自动解析出来Reserved，wtf!!!
作者你在更新日志里能不能说一句，666, i fu le you！
第四个建议：我之所以要查找怎么获取Reserved，是因为安装新版的时候，我一直选择的是：手动提供秘钥什么的。但是新版要这个我没有，两天的时间除了查资料，还有个最坑爹的事儿：
即使我费了九牛二虎之力弄到singbox配置的Reserved，但我手动把三个信息提供给脚本后，怎么测试都是无法获取IP，说没法注册到team，给我自动恢复到free。
我后来通过观察团队面板才发现，作者的脚本不管是menu还是warp-go，执行卸载的时候，都会从官方注销已经注册的账户，这对避免资源滥用而言是必要的；
但是大哥，注销账户诶，这么严重的操作不应该在脚本执行卸载的时候进行红字提醒吗？现在哪个网络账户的注销，都是让用户确认八百遍才完成^^，哎，我客户端账户都没了可不是用备份下来的信息再升级账户不成功么。
所以这个手动输入秘钥IP什么的功能，也应该有个提示，它的作用目前仅限于通过其他设备（比如手机）获取到的团队信息输入，而我想当然的用我vps上的一个三方客户端注册之后卸载掉的备份信息再用于另一个客户端使用，简直掉了大坑了。。。
其实最完美的方式，是脚本卸载的时候让用户手动选择，要是完全不用了按照目前方式处理，要是这个账户还使用，就自动生成一个备份文件是最好的；甚至说，脚本启动安装或者升级的时候，也可以先从这个备份文件读取，如果存在且有效，询问用户是否使用备份的秘钥IP等信息进行注册或者升级，而且卸载的时候也可以再次检查备份文件，如果有不同的账户信息，也一并询问是否对其进行注销。这样就会显得特别高大上了^^
（同时我想请问一下，我前面的*操作是warp-go注册后卸载了造成的，官方客户端我也这么弄过，账户都被注销了，但是如果我不卸载它们，我通过warp-go注册个账户并加入团队，然后用脚本给官方客户端和wgcf/api也用同样的秘钥信息加入团队，不是能5个吗，这应该可以对吧，但如果此时三个客户端都是使用一个私钥的时候，比如我用menu脚本卸载，是不是wgcf/api和官方客户端都没了吧？那warp-go的账户还有吗？也就是说，这个注销账户是会计数的还是注销一下全用不了了？要是全用不了了还麻烦了，那样使用你这个脚本一卸载，要是手机等其他设备也是这个账户，还一块用不了了呢）。
第五个建议：暂时没有了。
目前的问题：我把我先前上不了网的issues关掉了，但本次我使用3.0艰难的注册成功之后，哎，还是上不了网。跟以前的表现一样，warp提示是成功获取了IP的，curl官方那个trace网址，啥也不提示卡一下就完事了。
warp n 关闭了之后才能正常上网。
前次我说，很可能是MTU的问题不是么，但是目前我看又不是。
因为我使用3.0脚本现在不是注册了账户了么，我在xray里配置了出站的wireguard信息，我让出站的所有流量都走warp，MTU我还设置的1420，没有开启脚本安装的wgcf/api客户端，却完全可以正常使用，IP测试网站也全部显示cloudflare的ISP。
（先前我用2.50版本的时候，从脚本的客户端走，ip.sb这个网站经常性刷不出IP，或者v4v6只显示一个，我开的是双栈，但目前通过xray自带的走，感觉非常丝滑，每次都能显示完整的信息）。
因此我感觉咱这个脚本一定是哪个细节的设置有点问题，要么就是warp客户端本身有问题，但是老版本不是用的wgcf么，现在好像是改成API了，可问题依然存在。
Describe the solution you want / 描述你希望的解决方案
脚本的代码非常优雅，特别喜欢这个脚本，还是希望作者能抽时间检查检查。其实我有个想法：
就是可以额外开发一个debug版本，核心代码跟menu的一样，但是所有操作都记录到日志或者是错误日志，这样只要提供日志，在哪个地方出问题了非常容易找出原因。甚至可以有个后台轮询，自动检测为什么会没网了，记录详细信息到日志。如果作者能有这个计划，做出来我一定积极配合测试。
Describe the alternatives you are considering / 描述你所考虑的替代方案
以下是注册时的提示信息：
确认请按 [y]，其他按键则使用免费账户: y
创建快捷 warp 指令成功
运行 WARP
后台获取 WARP IP 中,最大尝试5次……
第1次尝试
第2次尝试
已成功获取 WARP Teams 网络 ============================================================== IPv4: 104.xxxx 美国 Cloudflare, Inc.
IPv6: 2a09:bac5xxxxx 美国 Cloudflare
恭喜！WARP Teams 已开启，总耗时:96秒， 脚本当天运行次数:7225，累计运行次数:4520305
IPv6 优先
【全显示成功，IP也获取，但此时却是断网状态，接着我重启了】
【重启之后依旧上不了网，我curl时v4没反应，但是v6显示正常了，经常是哪个IP都没反应。】
root@xxxx:~# wg
interface: warp
public key: z6T9riqnxxxx private key: (hidden)
listening port: 42547
fwmark: 0xca6c
peer: bmXOxxxx
endpoint: 162.xxxx
allowed ips: 0.0.0.0/0, ::/0
latest handshake: 12 seconds ago
transfer: 452.74 KiB received, 254.52 KiB sent
persistent keepalive: every 30 seconds
root@xxxx:~# warp n
后台获取 WARP IP 中,最大尝试5次……
第1次尝试
已成功获取 WARP Teams 网络
IPv4:104.28xxxxxxx United States Cloudflare, Inc.
IPv6:2a09:xxxxxx United States Cloudflare
root@xxxx:# curl -4skm 8 https://www.cloudflare.com/cdn-cgi/trace# curl -4skm 8 https://www.cloudflare.com/cdn-cgi/trace
root@xxxx:
root@xxxx:~# curl -6skm 8 https://www.cloudflare.com/cdn-cgi/trace
fl=619f59
h=www.cloudflare.com
ip=2a09xxxx
ts=16890xxxx
visit_scheme=https
uag=curl/7.81.0
colo=LAX
sliver=none
http=http/2
loc=US
tls=TLSv1.3
sni=plaintext
warp=plus
gateway=off
rbi=off
kex=X25519
I confirm that I have checked the history issues / 我确认已查询历史 issues
- Yes / 是
第一个建议：使用warp v 的时候，要是能先同步一下间隔版本的更新日志就好了。像最新的3.0改动较大建议重装，我是处问题了上这里才看到，在不知情的情况下直接升级了脚本，导致我知道应该重装的时候，用新版卸载旧版，也不知道这样是不是有问题，这给我后来的排查埋下隐患，总觉得是不是老版本没卸载对，所以后面的问题解决不了的时候，还去找了老版本又卸载一次。
的确这块没有处理得完美，新旧对比如下，也预见到会出现混乱，不过过了这一阵子就好了，毕竟是大重构流程
| 对比 | 关闭 | 开启 | 网络接口名 | 配置文件名 |
|---|---|---|---|---|
| 旧 | wg-quick down wgcf | wg-quick up wgcf | wgcf | /etc/wireguard/wgcf.conf |
| 新 | wg-quick down warp | wg-quick up warp | warp | /etc/wireguard/warp.conf |
第二个建议：我看最新版使用了wireguard-go，是为了使用保留字段Reserved，但毕竟三方实现不如内核的效率和稳定，为什么不通过脚本自动检测IP的地理位置或者让用户手动选择内核呢？这个保留字段是不是只有HK和LA地区的主机才需要？那样的话让所有地区的脚本用户迁就这两个地区，有点舍本逐末的赶脚。
1.按理来说是内核会优于 wireguard-go-reserved 的。但经过几位网友的对比， wireguard-go 与 内核相关无几，再结合一般是通过本地去连vps，差异就更显示不出来了。
2.现在我只有在一种情况下会使用内核模块，就是机器没有开tun同时又有 wireguard 内核的情况下，就启用内核。
3.至于你提到的HK和LA，好像除了这两个地区需要 reserved 外，暂时未发现。但有个问题是否，是否需要 reserved ，从 wg-quick up 运行的时候检测不出来，即是回显与其他的一样都很正常，就是获取不了 warp 服务，所以检测只能通过那些 ip api 网，像 ip.sb ，ip-api.com ，但如果写死在脚本里，我担心检测不准。
综合考虑，在没有很明确内核远快于wireguard-go-reserved的前提下，先一刀切用了 wiregaurd-go-reserved 了（当然这样我脚本也更容易处理）。
第三个建议：就因为这个Reserved ，我活活整了两天，因为老版本没有，更新日志和说明也没写到底从哪获取，我看issuse里也有人问，但作者都没回复^_^，我查了好多资料，终于找到个方法：
安装warp-go，导出singbox配置，会自动有这个Reserved ，还有人说注册官方客户端，在配置文件里有（然而并没有）。singbox那个好用，但这并不是最简单的方法，最简单的就是menu脚本，最初安装或者升级账户的时候，选择提供token（可以由作者提供的网址或者team主页开F12查看），token有时效需要快点复制，然后脚本竟然会……自动解析出来Reserved，wtf!!!
作者你在更新日志里能不能说一句，666, i fu le you！
reserved是从注册账户文件里提取的，具体可以见本项目的 cloudflare warp 官方api, 包括 teams 和 plus 账户，可以使用上述的 api 指定账户文件来获取这个 reserved 的值: https://github.com/fscarmen/warp/blob/main/README.md#cloudflare-api-%E8%BF%90%E8%A1%8C%E8%84%9A%E6%9C%AC
现在你可以完全不需要安装 warp-go，再导出 singbox 的，在这个网即可处理 https://fscarmen.cloudflare.now.cc/ ，在右上角有个 register warp 的按键，注册一个新账户，同时有 singbox 和 wireguard 的相应配置文件。
第四个建议：我之所以要查找怎么获取Reserved，是因为安装新版的时候，我一直选择的是：手动提供秘钥什么的。但是新版要这个我没有，两天的时间除了查资料，还有个最坑爹的事儿：
即使我费了九牛二虎之力弄到singbox配置的Reserved，但我手动把三个信息提供给脚本后，怎么测试都是无法获取IP，说没法注册到team，给我自动恢复到free。
我后来通过观察团队面板才发现，作者的脚本不管是menu还是warp-go，执行卸载的时候，都会从官方注销已经注册的账户，这对避免资源滥用而言是必要的；
但是大哥，注销账户诶，这么严重的操作不应该在脚本执行卸载的时候进行红字提醒吗？现在哪个网络账户的注销，都是让用户确认八百遍才完成^^，哎，我客户端账户都没了可不是用备份下来的信息再升级账户不成功么。
所以这个手动输入秘钥IP什么的功能，也应该有个提示，它的作用目前仅限于通过其他设备（比如手机）获取到的团队信息输入，而我想当然的用我vps上的一个三方客户端注册之后卸载掉的备份信息再用于另一个客户端使用，简直掉了大坑了。。。
其实最完美的方式，是脚本卸载的时候让用户手动选择，要是完全不用了按照目前方式处理，要是这个账户还使用，就自动生成一个备份文件是最好的；甚至说，脚本启动安装或者升级的时候，也可以先从这个备份文件读取，如果存在且有效，询问用户是否使用备份的秘钥IP等信息进行注册或者升级，而且卸载的时候也可以再次检查备份文件，如果有不同的账户信息，也一并询问是否对其进行注销。这样就会显得特别高大上了^^
（同时我想请问一下，我前面的*操作是warp-go注册后卸载了造成的，官方客户端我也这么弄过，账户都被注销了，但是如果我不卸载它们，我通过warp-go注册个账户并加入团队，然后用脚本给官方客户端和wgcf/api也用同样的秘钥信息加入团队，不是能5个吗，这应该可以对吧，但如果此时三个客户端都是使用一个私钥的时候，比如我用menu脚本卸载，是不是wgcf/api和官方客户端都没了吧？那warp-go的账户还有吗？也就是说，这个注销账户是会计数的还是注销一下全用不了了？要是全用不了了还麻烦了，那样使用你这个脚本一卸载，要是手机等其他设备也是这个账户，还一块用不了了呢）。
如果有之前 wgcf 安装时留下的 /etc/wireguard/wgcf-account.toml 文件话，可以通过上述提到的 api.sh 获取 reserved 值。
你不要太在乎teams，plus账户那些，teams账户同一个组织和邮箱能重复申请，同一个token在短时间（20秒内）也能在多台vps申请teams的，而plus的tg有机器人，直接取24PB的账户，也有 warp-clone 项目白嫖 24PB 的 license https://github.com/totoroterror/warp-cloner
在卸载的时间，已经有依赖确认了，所以我没有增加账户注销和存在多种warp方案时选择一个或者多个的交互了，也是出于你的思路，绝大多数用户不需要这些交互，账户删了没有所谓的，再弄也很快。
现在升级脚本，只是改脚本的内容，不会动账户性质的，所以也无需要另外处理。至于你谈到的如果是team或者plus账户的话，问是否备份不删除是可以做做，不过还是上面提到的，删了再建就是了，warp 对账户的管控是完全没有的，在2.X 脚本，卸载 wgcf 的时候，没有删除账户，是3.0 beta才有的。
你提到的3个客户端使用同一个私钥，由于他们的设备id不同的，所以卸载的时候只会删除自己的那个账户，这样也正好让 plus 把一些已经没有用的绑定设备删除，这个在 wgcf 是做不了（作者知道，但他没有动力做），故不存在你说的删一累全家的情况。
第五个建议：暂时没有了。
目前的问题：我把我先前上不了网的issues关掉了，但本次我使用3.0艰难的注册成功之后，哎，还是上不了网。跟以前的表现一样，warp提示是成功获取了IP的，curl官方那个trace网址，啥也不提示卡一下就完事了。
warp n 关闭了之后才能正常上网。
前次我说，很可能是MTU的问题不是么，但是目前我看又不是。
因为我使用3.0脚本现在不是注册了账户了么，我在xray里配置了出站的wireguard信息，我让出站的所有流量都走warp，MTU我还设置的1420，没有开启脚本安装的wgcf/api客户端，却完全可以正常使用，IP测试网站也全部显示cloudflare的ISP。
（先前我用2.50版本的时候，从脚本的客户端走，ip.sb这个网站经常性刷不出IP，或者v4v6只显示一个，我开的是双栈，但目前通过xray自带的走，感觉非常丝滑，每次都能显示完整的信息）。
MTU的导致没有网络的问题我也觉得不太可能。据我了解，xray配置里写 wireguard 链式代理，速度远远比不上直接在vps上直接使用wiregurad连接 warp 的，所以我建议在某些真需要warp的网站上分流就好了，比如chatGPT，不好大面积使用。
因此我感觉咱这个脚本一定是哪个细节的设置有点问题，要么就是warp客户端本身有问题，但是老版本不是用的wgcf么，现在好像是改成API了，可问题依然存在。
这个要等时间来说明和处理了。
MTU的导致没有网络的问题我也觉得不太可能。据我了解，xray配置里写 wireguard 链式代理，速度远远比不上直接在VPS上直接使用wiregurad连接 warp 的，所以我建议在某些真需要warp的网站上分流就好了，比如chatGPT，不好大面积使用。
感谢回复。
warp我肯定是需要的，我现在有问题的vps是专门用来魔法的，所以xray肯定有的；而不用作魔法的vps，还是非常需要warp和cloudflare的某些服务的。
那如果是必须有xray这种自带了wireguard协议的东西，额外再装warp的效率，从逻辑上说不一定高吧。
毕竟warp也是走wireguard，最前端xray一顿处理，再转发给本机的warp搞一顿，总觉着不如用xray自带的协议往cloudflare发更好呢。
至于分流吧，我是属于又懒又胆小的😂
我有两台设备需要常年模拟海外环境，其中包括一台装着海外卡的手机，我不知道我会访问什么网站，哪些网站不允许商用ip，还有哪些网站会泄露我的信息，包括被无目的的攻击等等，所以我也干脆一刀切了，为了保护我这台魔法vps，我就让所有的出站都从warp走，毕竟我是个半吊子，也不知道什么更合适的方式。
全套着warp效率肯定不高，但安全和效率本来就有些矛盾不是么。
而且目前来说，还有最最最关键的一点，我用你脚本安装的warp，它无法工作呀😂
而用xray自带的，目前看来还很丝滑。
MTU的导致没有网络的问题我也觉得不太可能。据我了解，xray配置里写 wireguard 链式代理，速度远远比不上直接在VPS上直接使用wiregurad连接 warp 的，所以我建议在某些真需要warp的网站上分流就好了，比如chatGPT，不好大面积使用。
感谢回复。 warp我肯定是需要的，我现在有问题的vps是专门用来魔法的，所以xray肯定有的；而不用作魔法的vps，还是非常需要warp和cloudflare的某些服务的。
那如果是必须有xray这种自带了wireguard协议的东西，额外再装warp的效率，从逻辑上说不一定高吧。 毕竟warp也是走wireguard，最前端xray一顿处理，再转发给本机的warp搞一顿，总觉着不如用xray自带的协议往cloudflare发更好呢。
至于分流吧，我是属于又懒又胆小的😂 我有两台设备需要常年模拟海外环境，其中包括一台装着海外卡的手机，我不知道我会访问什么网站，哪些网站不允许商用ip，还有哪些网站会泄露我的信息，包括被无目的的攻击等等，所以我也干脆一刀切了，为了保护我这台魔法vps，我就让所有的出站都从warp走，毕竟我是个半吊子，也不知道什么更合适的方式。
全套着warp效率肯定不高，但安全和效率本来就有些矛盾不是么。
而且目前来说，还有最最最关键的一点，我用你脚本安装的warp，它无法工作呀😂 而用xray自带的，目前看来还很丝滑。
如果你xray里使用了 warp 的链式代理，本机也不需要安装warp啦，只要把需要的流量分流过去可以了。
看你的魔法vps使用场景，还是warp全局更好点，至于后面又提到不能工作，这个真不清楚什么原因了。
第二个建议：我看最新版使用了wireguard-go，是为了使用保留字段Reserved，但毕竟三方实现不如内核的效率和稳定，为什么不通过脚本自动检测IP的地理位置或者让用户手动选择内核呢？这个保留字段是不是只有HK和LA地区的主机才需要？那样的话让所有地区的脚本用户迁就这两个地区，有点舍本逐末的赶脚。
2023.7.21 menu.sh 一键脚本 V3.00 beta2
-
If the system supports wireguard kernel and wireguard-go-reserved, it can be switched use [warp k], which requires a script reinstallation;
-
Support Fedora system;
-
Fix changing ip error caused by client version 2023.7.40-1.
-
如果系统支持 wireguard kernel 和 wireguard-go-reserved，可以通过 [warp k] 切换，需要重装脚本;
-
支持 Fedora 系统;
-
修复 client 2023.7.40-1 版本导致的开关错误。
