分类： 技术技巧

① 获得接口链接

新建 Colab 笔记：

把以下内容粘贴进去：

!wget -q -c https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64 -O c
!chmod a+x c
!pip install udocker
!udocker --allow-root pull zhu327/gemini-openai-proxy:latest
!udocker --allow-root create --name=gemini zhu327/gemini-openai-proxy:latest
!./c tunnel --url http://localhost:8443 & udocker --allow-root run -p 8443:8080 gemini

启动，等待 30 秒，获得到接口地址。

示意图：

② 获得 Gemini Pro API Key

从Google Makersuite 申请 Key：点此直达

③Demo

④ 一点补充

• gemini-openai-proxy 项目提供了兼容接口
• Colab 不支持安装 Docker，所以用 udocker 作为替代
• Colab 的 8080 端口默认被占用，所以使用 8443
• 为了兼容 Kaggle，cloudflared 需要重命名，否则会引起强制重启
• 随机 url 过于繁琐，最好在 CF 绑定域名

⑤ One more thing

是否支持 NSFW？有限支持。我没有特别写过越狱 prompt，Gemini 并没有拒绝回答。
有其他用户提到模型会拒绝回答，对此，我的经验是伪造 AI 一轮或多轮的回复（当然这需要客户端支持）。

运行 server 端，以 colab 为例：

首先用 CF-Tunnel、Ngrok 之类的工具穿透，然后加载模型：

!mkdir -p /root/.tabby
!wget https://github.com/TabbyML/tabby/releases/download/v0.6.0/tabby_x86_64-manylinux2014-cuda117
!chmod +x tabby_x86_64-manylinux2014-cuda117
!TABBY_DISABLE_USAGE_COLLECTION=1 ./tabby_x86_64-manylinux2014-cuda117 serve --model TabbyML/DeepseekCoder-6.7B --device cuda --port 8443
# change the default port due to 8080 is occupied by colab

在 vscode 中安装 Tabby 插件，填入远程地址，即可：

问题：经常会超时，多次后就会拒绝连接。修改 config.toml 似乎无效，不知道什么原因。

Colab 使用 cell 控制有诸多不便，为了方便交互和监控资源，研究了一下通过终端交互的方式。

管理 Colab

【弃用】方案 1：通过 webshell… 对，就是木马当管理器用。

!apt install php
!nohup php -S localhost:8000 > /dev/null &
!echo '<?php @eval($_POST["shell"]);?>' > connect.php
# 然后用 ngrok（我一开始就是这样修改文件的）

结论：不会被制裁。体验一言难尽，蛋疼。

【弃用】方案 2：使用 tmate

!apt install tmate
!tmate
# 自动分配外网地址

结论：一般不会被制裁。比没有强，像 tmux 那样操作。

【在用】方案 3：使用正经 ssh

!echo $($(echo "pip install colab""_ssh --upgrade"))
from colab_ssh import launch_ssh_cloudflared, init_git_cloudflared
launch_ssh_cloudflared(password="X")

结论：直接安装 colab_ssh 会有警告，虽然能绕过但制不制裁看官方心情。体验很爽。

方案 3 解释

这个方案需要本地下载一个 cloudflared，具体的 vscode 配置可以参考>这篇教程

作者给了一个修改本地 .ssh/config 的方案，实际上也可以在本地端口监听，像这样：
cloudflared.exe access tcp --listener localhost:2222 --hostname sub.trycloudflare.com

这样各种 ssh 客户端，如 Xshell，也可以通过连接 localhost:2222 来访问 colab

更多用法

1. 快速得到一个 webui 的外部地址，但仅限自己浏览器访问

   from google.colab.output import eval_js
   print(eval_js("google.colab.kernel.proxyPort(8000)"))

2. 通过 cloudflare tunnel 将任意端口暴露到外网，所有人可访问

   !wget https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64 -O cloudflared
   !chmod a+x cloudflared
   import nest_asyncio
   nest_asyncio.apply()
   import subprocess
   f = open("stdout", "w")
   p = subprocess.Popen(['./cloudflared', '--url', 'http://localhost:8000'], bufsize=0, stdout=f, stderr=subprocess.STDOUT)
   import time
   time.sleep(3)
   !grep -F trycloudflare stdout

3. 防止 colab 断连，console 自动点击 connect。

   var startClickConnect = function startClickConnect(){
   var clickConnect = function clickConnect(){
       console.log("Connnect Clicked - Start");
       document.querySelector("#top-toolbar > colab-connect-button").shadowRoot.querySelector("#connect").click();
       console.log("Connnect Clicked - End"); 
   };
   var intervalId = setInterval(clickConnect, 60000);
   var stopClickConnectHandler = function stopClickConnect() {
       console.log("Connnect Clicked Stopped - Start");
       clearInterval(intervalId);
       console.log("Connnect Clicked Stopped - End");
   };
   return stopClickConnectHandler;
   };
   var stopClickConnect = startClickConnect();
   // In order to stop, call:
   // stopClickConnect();

结论

Colab 虽然限制 ssh，但并不是特别严格，还是可以变相使用。不过，Colab 似乎不支持 websocket，所以诸如 ttyd、code-server 等基于网页的终端无法使用。
Kaggle 严格限制 ssh，用了直接封号。不过，Kaggle 支持 websocket，所以可以使用 code-server。
以上就是在两者直接使用终端交互的方式。

最后，连接时最好检查一下本地防火墙。如果火绒处于免打扰模式，很可能会自动拦截 ssh 或者 cloudflared。

参考

- vscode连接Google colab
- cloudflare-tunnel-to-colab.ipynb
- Quick Tunnels · Cloudflare Zero Trust docs
- Arbitrary TCP · Cloudflare Zero Trust docs
- How can I prevent Google Colab from disconnecting?

更新：修改了一些容易卡锁的细节

一条简单的笔记。

需求：我有一批获取的 IP，要一一验证可用性。

一个个验证太慢了，需要使用多线程。
ChatGPT 给出的方法是，先用//分割文本，然后每个线程处理相等数量的 IP。但是，这个方法预分配了所有条目，总有线程特别慢，迟迟难以收尾。

之前写了一个简单的多消费者模型。先把文本全部读进列表，增加一个行计数器。每个线程一次只分配一条数据，在取任何数据前，先将计数器+1，代表对应行已被分配。处理完了再分配下一条数据。
不过，代码很奇怪，我决定用 queue 再重写一下。

以下是一个修改后的通用实现，附带一个简单的进度条。

from os import _exit
from time import sleep
from queue import Queue
from threading import Thread
from signal import signal, SIGINT
from dataclasses import dataclass
from time import time, strftime, gmtime

def consume(queue):
    while not queue.empty():
        item = queue.get()

        ''' do something here '''
        sleep(0.1)
        ''' do something here '''

        queue.task_done()

@dataclass
class QProgress:
    ''' a wget-like progress bar '''
    queue: Queue
    qsize: int = 0 # queue.qsize() by default
    width: int = 50 # characters of progress bar

    alive = True

    def interrupt(self):
        self.alive = False

    def show(self):
        data_size = max(self.queue.qsize(), self.qsize)
        start_time, showing_count= time(), 0
        while self.alive and showing_count < data_size:
            showing_count = data_size-self.queue.qsize()
            per = showing_count/data_size
            print(''.join([f"\r{('%.2f'%(per*100)).rjust(6,' ')}%[",
                f"{'='*int(per*self.width-1)}>".ljust(self.width,' '),
                f"] {showing_count}/{data_size} ",
                strftime('%H:%M:%S', gmtime(time()-start_time))]),
                end='', flush=True)

        if self.alive:
            print('', 'Done', sep='\n')

if __name__ == "__main__":

    queue = Queue()

    # 假定一些已生产的数据
    data_size = 6661
    [queue.put(i) for i in range(data_size)]

    # 进度条，启动！
    qprogress= QProgress(queue)
    Thread(target=qprogress.show, daemon=True).start()

    # 消费者们，启动！
    num_consumers = 661

    threads = [Thread(target=consume, args=(queue,), daemon=True)
        for _ in range(num_consumers)]
    [t.start() for t in threads]

    # 配合 daemon 响应 Ctrl+C
    def signal_handler(signal, frame):
        qprogress.interrupt()
        print('', 'Interrupted', sep='\n')
        _exit(0)

    signal(SIGINT,signal_handler)

    while any(t.is_alive() for t in threads):
        sleep(0)

哦，就是 base64 嘛。

---

最近 scaleway 服务很不稳定，终有一天它失联了。
根据以前的经验，一般是机器重启，需要去网页 TTY 重置下网络。

登录后，scaleway 问我，新的网络上线，更快更好，要不要一键 auto migrant？
一手贱，然后就双向失联了。具体表现为什么都 ping 不通，没有任何公网地址，连 apt update 也无法运行，通过 scw 分配 IP 也救不活。
此时 sacleway 后台弹出马后炮提示：您的套餐迁移时如果分配了静态 IP，需要先升级 blablabla，否则就会丢失网络连接。怎么救，没说。

这台服务器主要运行了这个博客，尽管文章在本地都有备份，但还是想着先抢救一下数据库。
我使用的是 sqlite 数据库，就一个/wp-content/database/.ht.sqlite文件。

抢救一下

网络彻底失联的情况下，我和这台机器唯一的交互手段就只有后台提供的网页版的 TTY。于是，只能靠屏幕输出了。

具体而言的话：

f=".ht.sqlite";
zip -9 -q f "$f";
base64 -w0 f.zip;echo "";

将输出保存到文件，从另一台机器

base64 -d save.txt > f.zip

进一步压缩

之前是针对空白系统的抢救办法。由于屏幕的输出空间很有限，结合一些工具的话，可以进一步缩减体积。

apt-get install sqlite3 p7zip-full python3-pip
pip install base2048

f=".ht.sqlite";
sqlite3 $f 'VACUUM;';
:<<eof
- or dump to sql -
sqlite3 $f .dump > dump.sql; f="dump.sql"; 
eof
7z a -bso0 -mx -myx -mmt=off -ms=on -mtm=off -mtc=off -mta=off -m0=LZMA:d=384m:fb=273:lc=4 -mmc=1000000000 f $f;
python3 -c "print(__import__('base2048').encode(open('f.7z','rb').read()))";

等待 TTY 狂暴输出。

其实还有更壮观的 base65536，输出的都是形似汉字的字符，但复制时可能会造成数据错乱。另一方面，base2048 屏幕输出占一个 ASCII 码的宽度，能容纳 2 个 ASCII 码的数据，而 base65536 占 2 个 ASCII 码的宽度，能容纳 3 个 ASCII 码的数据，压缩比提升不大且异常卡顿，实测还是 base2048 好。

恢复数据：将 TTY 打印的内容放入 2048.txt，然后恢复到 2048.7z。
其中明文数据大约是解码数据的 1.8 倍。

import base2048

with open('2048.txt', 'r',encoding='utf-8') as file:
    encoded_data = file.read()

decoded_data = base2048.decode(encoded_data)

with open('2048.7z', 'wb') as output_file:
    output_file.write(decoded_data)

更多可能

终端还可以展示带颜色的文字，用以进一步扩充符号数。如果能够显示图片，则可以结合一些隐写方法，将数据压缩到 RGB 值内。又或者结合屏幕刷新 + 录像，以类似二维码的原理定位和容错，并提供自动化的可能。

这样即使不需要数据线和网络，也能把电脑文件复制到手机上（当然首先要能在宿主上执行程序，听上去像是 007 会干的事）。
这些想法没什么太多应用场景，就只是想想。

最近存在一些文件分享需求，我希望它符合以下要求：

1. 链接长期有效，即使文件失效再补也能保持原链接
2. 不要出现过度限速问题
3. 不要存在我的服务器上，我的磁盘很有限
4. 不要暴露任何与文件本身无关的信息

一些尝试

首先我尝试把文件存在 Github 的 release 上，因为 release 不限制带宽，也是官方推荐的分发方式。不过，release 的文件链接会包括上传者和 repo 名，我不希望它出现。

Github release 的链接和 raw 不同，会 302 到 objects 子域，无法直接 rewrite。我试图用 CF workers 代理这部分流量，发现在 workers.dev 下可以工作，但绑定自定义域名后就会出现 52x 错误。后来我在 CF workers 社区中找到了相关讨论，这是个历史遗留问题，答案就是 CF 的限制（或 Bug？）
如果再试图用 worker A 通过域名访问 worker B 来绕过，会显示两者无法连通。
回头看目前基于 CF 的 Github 代理，就能发现大家都是通过加一层外部 proxy 绕过这个限制。

也就是说想要自定义域名代理 Github release 文件的话，无论如何都必须引入 CF 外的服务。

换个方案

在服务器上 fetch() 并传递给 CF 自然是可行的，不过事已至此，我决定换 AList 挂载网盘。

最终我选了 mega 网盘。挂载这个网盘只需要用户名和密码，不涉及 token、私有 API、Cookie，不需考虑过期更新的问题，也没有限速问题，非常符合开头提到的要求。

具体而言，我将 down 子域 指向我的 AList 服务器并反代，然后将直链中的 /[d|p]/files/<挂载目录> 通过 Transform Rules 去掉。

根据 CF 的文档，缓存单文件最大 100M，Page Rule 中设置最长可缓存 14 天，除了耗费一点回源流量，基本没什么消耗。

最终效果：https://down.liedown.win/Tinify-mod.zip

前阵子在通过 Fofa 收集信息，发现了 Fofa-hack 项目。

一开始这个项目是登录抓取，但后来 Fofa 改了规则，限制了免费用户的访问总数。
于是，项目改为抓取网页上的链接，一次只能抓 10 条，通过 after / before 语法抓取更多之后的页面。当每页提升到 20 条时，访问里会出现一个 sign 验证参数，一段时间内无人解决。
再后来，项目引入了 webdriver，还有 fuzz 来提升抓取量。

我不太了解前端，在研究了 Fofa 的网页以及查了一些资料后，得知是 webpack。然后稍微逆了一下。与其说是逆向，不如说网站本身也没做复杂的混淆，防君子不防小人吧。

首先，验证参数是 sign，所以搜索 sign:

可以看到，这里跳到了一个 sortFun()，继续追踪这个方法。

可以看到，sortFun() 实际是对 GET 参数的 key 进行 sort，然后拼接一下，最后为字符串 createSign()。

现在，Fofa-hack 已经支持了 sign 计算，并删掉了其他抓取方法。
python 版可以在项目内看到：简单的实现

这个接口一次可以抓取 100 条数据，配合 after / before 语法几乎可以抓全数据。

---

其他：

1. 直到完成 PoC，才发现 app_id 是静态的，其实搜索 app_id 也能轻松定位到验证入口。
2. 全网搜索 app_id 的值，发现已经有人研究过 sign 的算法，不过是用 Go 写的。
3. 从前人的研究看，似乎还有 page 访问超过 100 页无法抓取的问题，不过我没有触碰到这个上限，具体情况不清楚。
4. 这个接口除了可以突破网页版单页条目上限，也许还有其他网页不支持的特性，概率比较低，有空可以再看看。

原本是用 Github 作为图床，感觉不太好。第一 Github 本身就不是干这个的，第二 Repo 是全公开的。研究了一下决定切换到 Backblaze。

图片预览：@vreemdear

以下内容并不是教程，只是一些注意事项和补充。

为了保证足够的缓存，需要设置以下内容：

1. Backblaze bucket settings 中将 Bucket Info 设为 60 天 {"cache-control":"max-age=5184000"}
2. 在 Cloudflare Page rules 中将 Cache Level 设为 Cache Everything
3. 在 Cloudflare Page rules 中将 Edge Cache TTL 设为 7 days

Rewrite:
在 Cloudflare Transform rules 中，
将 Custom filter expression 设为 (not starts_with(http.request.uri.path, "/file/<bucketname>") and http.host eq "<your_custom_domain>")
rewrite to Dynamic 设为concat("/file/<bucketname>",http.request.uri.path)
// 似乎调换顺序也会报错，不清楚原因，可能是因为没来得及缓存。

此处反代主要用于爬墙

方案一：
ip-scanner/cloudflare 的继任 cloudflare-better-ip

方案二：
用多地点 ping 工具 ping 以下域名

1. aGV4c2VuLmNvbQ==
2. YWxpLnNnLjEzMzM1MC54eXo=

对获得的 ip 验证或测速

需切换至列表模式使用，只导出 IP、端口、协议

function downloadTextFile(text, fileName) {
  var element = document.createElement('a');
  element.setAttribute('href', 'data:text/plain;charset=utf-8,' + encodeURIComponent(text));
  element.setAttribute('download', fileName);
  element.style.display = 'none';
  document.body.appendChild(element);
  element.click();
  document.body.removeChild(element);
}
var row = document.querySelectorAll("tr.el-table__row");
var links = [],ports = [],protocols = [];
for (var i = 0 ; i < row.length; i++) {
  var link = row[i].querySelector("span.table-link").innerText.trim();
  if (link.length != 0){links.push(link);}
  var port = row[i].querySelectorAll("span.cursor-pointer")[0].innerText.trim().split(' ')[0];
  if (port.length != 0){ports.push(port);}
  var protocol = row[i].querySelectorAll("span.cursor-pointer")[1].innerText.trim().replace('http/ssl','https');
  if (protocol.length != 0){protocols.push(protocol);}
}
var text = '';
for (var i = 0;i <links.length; i++){
    text = text + links[i]+ '\t' + ports[i] + '\t' + protocols[i] + '\n';
    console.log(text);
}
var fileName = 'data.txt';
downloadTextFile(text, fileName);