使用 ShellCrash 代理 1Panel Halo 谷歌站点推送|无聊罐子的觅风之旅

前言

之前一直没搞懂这个站点推送工具是怎么用的，偶尔一次瞎搞搞成功了就不想再动了。后来换过一次域名，换了几次云服务器，由于代理工具忘记怎么弄了，而且站点收录的 token 什么的也发生了变动，一直懒得弄。直到我发现先前的一篇关于 clash steam 直连的文章还有人看，竟然还留了评论（不过之后删掉了），这才发现站点推送的重要性，这是实打实地能被搜索引擎搜到的。

于是现在重新折腾，到开始写文章这里，本人已经折腾了 10h + 了，仍然云里雾里，没有成功，最后推断是站点收录插件的问题。但阅读这篇文章，可以看到我踩的坑，发现一些我不懂得原理但十分神奇的现象，也可以获得一些ShellCrash的使用经验。

代理工具的选择

声明：本人仅用代理工具来进行谷歌的站点推送，目的是分享知识，不会做其他任何违法犯罪的事情。

clash for windows 已经关仓跑路了，surf 了一下后发现了 ShellCrash 这个工具，于是搞下来研究。

按照教程安装好后，折腾了半天无果，无法成功收录。无法收录的原因有很多：可能是代理没有配置好、也可能是站点收录的 token 那些没有配置好、halo容器的网络模式不是桥接... 所以很难定位问题，而且中途踩坑才发现，ping 走的是另外一种协议，即使开了代理，你 ping 谷歌也是 ping 不通的，你得 curl。导致我一直以为代理没开好。

测试代理效果

云服务器开放端口，在windows上用curl来测试代理（不行，但后面发现多curl几次能偶尔通）

先在 crash 中启用公网访问Socks/Http代理，否则下面的 curl 会不通

在 windows terminal 中使用 curl -v -x http://name:pwd@ip:port https://api.ipify.org 后，得到了如下的结果。

我故意把鉴权的用户名和密码输错之后，得到的状态码是407，而图中是404，说明端口成功开放了，但是不知道为什么404了（后面发现是概率问题，多试几次总有一次能 curl 通）。

折腾半天也没搞明白为什么，遂放弃。

通过ping来判断代理

我先按照这个人的教程（不懂 singbox 的不要更着做，我后面换成 meta 内核了），把内核改成了singbox，以及一系列其他的配置：https://ovnrain.com/post/shellcrash-tutorial

大概是这些：

安装 sing-box 内核
选择 9 更新/卸载 - 2 切换内核文件 - 2 SingBox，此时 ShellCrash 会自动下载内核文件并安装，选择 0 不保留相关数据库文件。
安装本地 Dashboard 面板
在保持 9 更新/卸载 的菜单中，选择 4 安装本地Dashboard面板 - 2 安装Yacd-Meta魔改面板，安装完成后选择 0 返回上级菜单，此时会提示 是否加载为singbox的配置文件，选择 1 加载。
配置 ShellCrash 运行
在 crash 主菜单中，选择 2 内核功能设置：
1 切换防火墙运行模式 选择 3 Tproxy模式
2 切换DNS运行模式 选择 3 mix混合模式
7 屏蔽QUIC流量 开启
在 crash 主菜单中，选择 7 内核进阶设置 - 4 启用域名嗅探 开启。

然后我试着ping了一下，baidu.com 能通，bing.com 不行，google.com 也不行。一看站点收录插件，也只有百度能成功收录，之前必应也可以的，现在配置好 ShellCrash 后又不行了。

当我把 ShellCrash 停止之后，ping bing.com 又可以了。

后面网上搜索到。（下面说的ping不通指的是，ping不通谷歌很正常，但ping不通百度就不应该了）

·为？什？么？PING？不？通？
ping命令基于ICMP协议，clash暂不支持代理ICMP协议，请使用curl或直接浏览器访问进行测试！！！

所以切换到curl来判断是否成功：

root:~# curl baidu.com
<html>
<meta http-equiv="refresh" content="0;url=http://www.baidu.com/">
</html>
root:~# curl -o /dev/null -s -w "%{http_code}\n" https://www.bing.com
200
root:~# curl -o /dev/null -s -w "%{http_code}\n" https://www.google.com
200

curl -x http://127.0.0.1:7890 https://google.com 也是成功的，这就说明代理的的确确挂载在7890端口了。

解决 ping 不通baidu.com的问题

把内核换成meta，dns模式换成redir_host，不要使用fake-ip，就可以了。

解决curl测试代理失败的问题

netstat -tuln | grep 7890 
tcp6 0 0 :::7890 :::* LISTEN 
udp6 0 0 :::7890 :::*

GPT 的回复是：

你的程序正在监听 IPv6 通信地址（[::]），但当你尝试连接 127.0.0.1:7890（IPv4 地址）时，系统无法匹配到对应的服务，导致连接被拒绝。
理论上，现代系统中 IPv6 和 IPv4 会有映射机制，但有些配置下可能没有正确生效，所以你看到这个连接失败的情况。

于是在 /etc/ShellCrash 下找到 config.yaml ,在里面添加 bind-address: 0.0.0.0 ，再重启 crash 。

然后在终端中输入 curl -v -x http://name:pwd@ip:port https://api.ipify.org ，得到了正确的结果。

但这个时候如果 curl -v -x http://name:pwd@ip:port https://google.com ，得到的仍然是 404，似乎只有https://api.ipify.org 能成功。（后面发现其实是概率问题）再次打开 config.yaml ，配置文件竟然被自己改回去了。看来每次启动 crash，配置文件都会被 crash 的设置覆盖一次。

寻找配置文件

 1 启动/重启服务
 2 内核功能设置
 3 停止内核服务
 4 内核启动设置
 5 配置自动任务
 6 导入配置文件
 7 内核进阶设置
 8 其他工具
 9 更新/卸载
-----------------------------------------------
 0 退出脚本
请输入对应数字 > 6
-----------------------------------------------
 ShellCrash配置文件管理
-----------------------------------------------
 1 在线生成meta配置文件
 2 在线获取完整配置文件
 3 本地生成providers配置文件
 4 本地上传完整配置文件
 5 设置自动更新
 6 自定义配置文件
 7 更新配置文件
 8 还原配置文件
请输入对应数字 > 6
5 自定义高级功能

之后就会在/etc/ShellCrash/yamls 下创建user.yaml ，在里面可以进行自定义配置，于是写入bind-address: 0.0.0.0 ，仍然没有用。

发现偶然性，原来是概率事件

重复地进行 curl 试验，发现偶尔能够连接成功，大概是 1/8 的概率。但即使是 1/8 的概率，站点上传工具也没有一次成功。

并且，前面做的关于修改bind-address 的操作也都是在扯淡，完全不需要这么弄。

锁定配置文件（失败）

最后再试一试刚刚发现的锁定配置文件，孤注一掷了。

 1 启动/重启服务
 2 内核功能设置
 3 停止内核服务
 4 内核启动设置
 5 配置自动任务
 6 导入配置文件
 7 内核进阶设置
 8 其他工具
 9 更新/卸载
-----------------------------------------------
 0 退出脚本
请输入对应数字 > 6
-----------------------------------------------
 ShellCrash配置文件管理
-----------------------------------------------
 1 在线生成meta配置文件
 2 在线获取完整配置文件
 3 本地生成providers配置文件
 4 本地上传完整配置文件
 5 设置自动更新
 6 自定义配置文件
 7 更新配置文件
 8 还原配置文件
-----------------------------------------------
 0 返回上级菜单
请输入对应数字 > 6
-----------------------------------------------
 欢迎使用配置文件覆写功能！
-----------------------------------------------
 1 自定义端口及秘钥
 2 管理自定义规则
 3 管理自定义节点
 4 管理自定义策略组
 5 自定义高级功能
 9 禁用配置文件覆写
-----------------------------------------------
 0 返回上级菜单
请输入对应数字 > 9
-----------------------------------------------
此功能可能会导致严重问题！启用后脚本中大部分功能都将禁用！！！
如果你不是非常了解meta的运行机制，切勿开启！
继续后如出现任何问题，请务必自行解决，一切提问恕不受理！
-----------------------------------------------
我确认遇到问题可以自行解决[1/0] > 1
-----------------------------------------------
设置成功！
-----------------------------------------------
 欢迎使用配置文件覆写功能！

然后去修改/etc/ShellCrash 下 config.yaml ，看会不会被自动改回去。

把上面部分改成：

port: 7890
socks-port: 7891
allow-lan: true
bind-address: 0.0.0.0
mode: Rule
log-level: info
external-controller: :9999

结果 crash 直接启动不起来了，回滚。

不想折腾了

在 halo 容器的同一个 docker (172.18.0.0/16)网络中，安装一个 alpine 容器，在内部安装好 curl ，然后curl -v -x http://name:pwd@172.17.0.1:port https://google.com ，每次都可以正常通过，但为什么 halo 的站点推送插件一直没反应呢。

并且后面了解到，halo的容器本质上也是Ubuntu，于是安装curl，不管是用服务器的公网ip还是docker的网关 172.17.0.1 ，都能够正常走代理，这次才发现，根本不是代理的问题，也许是站点收录插件的问题，或者谷歌token错误。由于插件并没有给出任何日志，我也无从得知原因。

（反思总结）为什么这个问题花了这么多时间

因为踩了很多坑，首先是ping不通baidu、google，但能ping通bing，之后换成singbox内核之后，baidu也ping不通了。

上网一顿乱查，以为ping不通是正常的（实际上只有ping不通google才是正常的）。

并且我查代理能不能用的办法是，在windows上用云服务器的公网ip进行curl，这个竟然是一个概率成功事件，导致我以为是没有配置好（不过概率性事件也不正常）。

搞个了十几个小时之后，换成meta内核，dns不用fake-ip，ping的情况就正常了。

并且这次彻底换了一个思路，在172.18.0.0/16 这个网络下的容器，不管是用服务器的公网ip还是docker的网关 172.17.0.1 作为代理进行curl，都能够100%走通，并不像windows上面那样是概率性事件。

后续：查看站点推送日志

2025-02-10T22:04:55.707+08:00  WARN 7 --- [hReconciler-t-1] c.s.s.strategy.AbstractPushStrategy      : Push exception: google : null

百度和必应相关的日志都正常，也返回了code：200，但谷歌的是null，非常奇怪

在给的json认证文件中包含了两个这样的地址，我印象中有个地方提示我需要开启oauth。

"auth_uri": "https://accounts.google.com/o/oauth2/auth",
"token_uri": "https://oauth2.googleapis.com/token",

是在这个链接中： https://console.cloud.google.com/apis/credentials

现在我怀疑问题的根本是没有配置这个信息，于是去进行一番配置，静候佳音------没有成功

后续：谷歌通知被“noindex”标记排除了

原来是 halo sitemap 插件中的 robots.txt 被我关掉了，现在打开试试。额...依然没有用

前言