月度归档： 2025 年 1 月

服务器因为用过warp脚本后定期失联的问题已经困扰我很久了。

用尽各种方式，以及各种缓解手段，服务器最后还是失联，甚至都找不到任何可疑的进程或服务。试了下debian，也是没辙。

俗话说天下无难事，只要肯放弃。

新开一个服务器，再也不碰warp了，以后就用redsocks+分流的方案。

本站跑在Scaleway的纯IPv6服务器上，之前为了给它加上IPv4，用了Cloudflare warp脚本。

不知道从什么时候开始，服务器就开始经常掉线、失联，也查不出什么问题。后来，换了个脚本，服务器倒是不失联了，但就是连不上，表现为明明已经获得了IP，但不走warp线路。

所以，我决定索性放弃一键warp，只借用Cloudflare补全IPv4就行。

简单来说，新方案是在worker上部署一个vless服务，然后让IPv4走socks代理，IPv6不走代理。

配置代理

先找到另一台双栈服务器搭建服务，然后在本地创建socks5代理。

这里有个现成的在Cloudflare worker上部署vless的方案。
在Cloudflare面板里创建一个worker，然后把这个代码粘贴进去。
Cloudflare屏蔽vless关键词，现将它全局替换成其他词，然后把userID改为自己的UUID。

这就已经部署完了，不清楚vless配置的话访问 https://【your_domain】.workers.dev/【UUID】

一点小毛病

Worker无法访问已经套了Cloudflare CDN的网站。如果配置了socks5Address，就会改走socks5代理。没条件自己搭建socks5代理，或者不在意安全性，可以用这个修改版，里面内置了代理IP。
甚至也可以不配置，只是一些网站不能访问。

现在已经可以跳到下一个步骤——测试连通性。

如果一定要完全访问，且在意安全性，这里有两个方案。

【方案1：自有服务器搭建socks5】

找一台IPv4服务器，用glider配置socks5，例如：
./glider -listen user:pass@[::]:5005
然后将 socks5Address设定为user:pass@【yourServer】:5005

【方案2：无自有服务器建立代理链】

使用任意支持IPv4的代理服务，用CloudFlare作为跳板，承接所有流量。
例如：在HuggingFace Space上建立一个vless服务（复制别人的项目作为参考）
本地连接命令形如：./glider -listen :14159 -forward=wss://【CF-sub】.workers.dev,vless://【CF-UUID】@,wss://【HF-sub】.hf.space,vless://【HF-UUID】@
此时，CloudFlare仅用于桥接用途。

测试代理连通性

由于我的VPS可以直连Worker，所以没有绑定域名。

在服务器上用glider测试一下IPv4连接：

./glider -listen=127.0.0.1:14159 -forward=wss://【your_domain】.workers.dev/?ed=2048,vless://【userID】@

# 有结果，代表CF代理正常。
curl -4 -x socks5h://127.0.0.1:14159 https://google.com

# 有结果，代表可访问CF CDN网站（非必要）
curl -4 -x socks5h://127.0.0.1:14159 https://stackoverflow.com

配置redsocks

安装：apt install redsocks

socks5代理将运行在14159端口，对应的/etc/redsocks.conf配置如下：

base {
  log_debug = off;
  log_info = off;
  daemon = on;
  redirector = iptables;
}
redsocks {
  local_ip = 127.0.0.1;
  local_port = 12345;
  ip = 127.0.0.1;
  port = 14159;
  type = socks5;
}

# 启动redsocks
systemctl restart redsocks
systemctl enable redsocks

设置IPv4转发

# 启用IP转发
sysctl -w net.ipv4.ip_forward=1

# 配置规则
iptables -t nat -N REDSOCKS
iptables -t nat -A REDSOCKS -p tcp -d 0.0.0.0/8 -j RETURN
iptables -t nat -A REDSOCKS -p tcp -d 10.0.0.0/8 -j RETURN
iptables -t nat -A REDSOCKS -p tcp -d 127.0.0.0/8 -j RETURN
iptables -t nat -A REDSOCKS -p tcp -d 169.254.0.0/16 -j RETURN
iptables -t nat -A REDSOCKS -p tcp -d 172.16.0.0/12 -j RETURN
iptables -t nat -A REDSOCKS -p tcp -d 192.168.0.0/16 -j RETURN
iptables -t nat -A REDSOCKS -p tcp -d 224.0.0.0/4 -j RETURN
iptables -t nat -A REDSOCKS -p tcp -d 240.0.0.0/4 -j RETURN
iptables -t nat -A REDSOCKS -p tcp -j REDIRECT --to-ports 12345

iptables -t nat -A OUTPUT -p tcp -d 0.0.0.0/0 -j REDSOCKS

# 如果 ip -4 route 结果为空，则需要
# 添加虚拟网关
ip addr add 192.0.2.1/24 dev lo
ip route add default via 192.0.2.1 dev lo

curl -4 google.com试试，应该有结果了。
如果成功，将转发脚本加入开机启动。

顺便解决一下ping问题

由于ping是无法通过socks5代理的，可以用tcping作为替代。

wget -c https://github.com/cloverstd/tcping/releases/download/v0.1.1/tcping-linux-amd64-v0.1.1.tar.gz
tar -xf tcping-*.tar.gz && rm tcping-*.tar.gz
chmod +x tcping && mv tcping /usr/bin
echo "alias ping=tcping" >> ~/.bashrc

至此，tcping完全取代了ping。

总结

本文提供了一种用redsocks搭配iptables，为纯IPv6服务器添加访问IPv4能力的方案。

好处是灵活、稳定，自有双栈服务器的话，也可以不依赖Cloudflare。

之前，我在找一个国内可以稳定访问，托管静态页面的地方。记得十年前这种东西很多，如今居然很难找到。

一开始我用的是 华为云函数工作流，根据介绍，每个月前100万次调用是免费的。实际用了一下，才知道现在的云服务这么复杂。免费的只是函数调用次数，而公网流量、网关调用、CPU用时、存储，都要单独计费。

后来我了解了一下其他云服务，计费方案也是特别复杂，如果要走OSS方案，很多云起步都是1G，还必须先预付费100元。这对于我这种只托管一个HTML的用户来说是在大材小用。

我又寻找了一下类似Github Page的托管服务，发现国内基本也都关闭了，只剩下一个 开放原子基金会，要申请才能开通。

最终，还是在阿里找到了好东西，不过不是阿里云，而是 支付宝小程序-云开发。云开发下面有个免费配额，其中就有一项是免费静态托管。月配额：容量 155G，CDN流量1G。

续费最多可以续2个月，一个多月续一次就行了，没什么复杂的计费策略。
开通后自带一个测试用的网址，不嫌网址长的直接用就行了。

最近需要在国内建立一个纯静态的小网页，html只有10K，还有几个js和css。我不需要自定义域名，但要求微信能稳定访问。

国内没什么免费资源，我就从国外开始找，最终没找到特别好的，要么速度快但个别地区超时，要么不能绑定域名而且被微信拦截…… 我甚至试过把文件托管在有直链的网盘里（例如：城通、123pan，因为原本有会员），但速度或稳定性也不够好。

目前，我姑且在国内云上建立了个函数用来展示网页，又因为种种计费原因，我需要把js文件都托管到别处，于是便有了这篇文章。

公开的资源CDN

一些公共资源有很多文章盘点过了，稍微做个点评

微软Ajax CDN：部分地区不稳定
字节跳动：更新不够快，堪用
又拍云：几个热门库
360：首页不能访问，一些热门资源还能用
饿了么：反代UNPKG但不全
知乎：反代UNPKG但不全
WebCache：很多热门项目
渺软公益 CDN：支持所有回源，兜底

公共但小众的CDN

总的来说，公共库想要全，得像渺软公益CDN反代，而且没命中的要回源。

我收集了一些小众的：

红十字会：unpkg.crcf.cn
瑞幸咖啡：unpkg.luckincdn.com
航天金穗：unpkg.cdn.htjs.net
高灯科技：unpkg-com.goldentec.com
左柚耳机：jscdn.zooyo.club
晓雨科技：unpkg.rain-tech.net
……

还有更多小公司和个人搭建的，以上只是部分。

另类的CDN

反代主要是解决npm托管一些个人JS，公共JS要是能在国内就最好了。问题是，公开的CDN上不一定有想要的JS项目，稳定性也不一定好，所以想到个很神奇的办法——借用腾讯。

腾讯旗下项目众多，总会用到各式各样的JS，流量无限自带CDN。最重要的是域名统一，好找。例如用 Zoomeye 找一下clipboard.min.js，再点Body，就能从响应里看到JS的地址了。

有时会遇到同名不同项目的JS，比如 海贼王的JS 和 三角洲行动的JS 就不是同一个，可能需要多试一试。

总结

关于HTML的托管暂时还没有很好的办法，尽管UNPKG支持显示HTML，但不支持带参数（给JS调用填充页面），虽然直接用云函数成本也很低，但以后文件多了就麻烦了，还是得找找替代方案。

最近几个月，小破VPS总是每隔几天就失联。一开始以为是磁盘满了，但是清理后还是经常失联。查看了日志，也没找到原因。

这是一台纯IPv6机器，使用p3terx的warp脚本获得IPv4支持，所以严重怀疑是warp掉线的问题。我设置了每隔半天重置一次，结果过几天还是失联。

最终，我在作者的日志中找到了说法：

表现为隔一段时间就断网，重启后恢复。常见于 Ubuntu + 双栈全局网络。
可能的原因：

- Ubuntu 系统不稳定
- 性能不足导致的崩溃

解决思路：重启！重装！重买！
解决方法：
- 更换为宇宙最稳定的服务器操作系统——Debian
- 购买更稳定好用的 VPS，能花钱解决的问题都不是问题。

好吧，其实就是作者也没找到原因。这个问题确实是突然某一天开始出现的，也许是和什么包有冲突？

总之，现在换了个脚本：

wget https://gitlab.com/fscarmen/warp/-/raw/main/menu.sh
bash menu.sh

试用了各种选项，经历了五花八门的error，现在开启了IPv4单栈…… 但我完全不记得是什么选项在生效，可能是MASQUE协议+socks什么什么的。

总之先观察看看会不会炸。

最近有人提到了百度飞桨的免费GPU算力，所以就看了下。
目前飞桨每天提供8算力点，可以用四个小时16G V100。

和Kaggle相比，两者免费总时长差不多，不过体验有些区别：

• 飞桨默认16G V100 ，Kaggle默认16G T4双卡
• 飞桨可选32G V100，时长相应也只有一半
• 飞桨自带Code Server，可以和Jupyter一起用
• 飞桨没有root权限，不能apt install
• 飞桨有100G的空间，Kaggle只有20G
• 飞桨的联网很成问题，要先搞定代理

以上除了硬件限制，其他都是可以绕过的。总体而言，由于绘图不能分卡加载的缘故，飞桨适合需要大显存的绘图场景，不过相应的每天只能用2小时。

开始正题，如何使用vscode远程连接？

最简单的答案：使用 handy-ssh 开启一个简单的ssh server，然后使用 netapp 进行穿透。结束。

接下来是一些细节，甚至创建虚拟的root环境，算是对colab、kaggle、huggingface space折腾成果的综合应用。

一些细节

持久化

首先是持久化，/home/aistudio/external-libraries 是永久保存的。任何环境配置都应该在这个目录下进行。
使用code server，新建终端，可以同时运行多个命令。

必要的代理

强烈建议先配一个梯子 + proxychains 强制代理。
尽管本文未用到proxychains，但还是建议配一个，这会减少很多麻烦（例如 直接从github拖东西，而不需要找镜像、手动上传，或是翻阅各个软件的代理配置）。

我的方案是 glider 连接 vless，二进制文件直接通过code server传上去即可。

# 在9050开启socks5和http代理，服务器必须是443端口的
./glider -listen :9050 -forward wss://HOST/PATH,vless://UUID@

# 自行编译proxychains，bin+.so+config
./proxychains4 -f config.conf YOUR_COMMAND
# 配置见/src/proxychains.conf，最后socks4改为socks5

建立ssh server

接着把 handy-ssh 传上去，开启一个22122端口的ssh server，用户名为aistudio，密码为root

./handy-sshd --user aistudio:root -p 22122

自建穿透服务

选择netapp穿透的原因是，飞桨对端口卡得恨死，而netapp的服务正好在443端口。由于注册netapp需要身份证，嫌弃的话也可以自己搭一个。

我用的是 wstunnel

# 服务端
./wstunnel server ws://127.0.0.1:PORT -r PASSWORD

我是用nginx将PORT反代，同时加上证书和域名，这样就得到了一个443端口的穿透专用服务。

./wstunnel client -R tcp://0.0.0.0:22122:localhost:22122 wss://HOST -P PASSWORD

在飞桨里连接服务器，这样就完成了ssh server的部署。

最后通过vscode连接到aistudio:root@HOST:22122。

不需要root环境的话到此为止。

ROOT和开发环境的持久化

使用miniconda将udocker部署到持久化目录，再通过udocker获得一个root权限的容器，以运行简单的apt install。

安装miniconda

# 安装miniconda3并创建独立环境my_env
wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh -O ~/miniconda3/miniconda.sh
bash miniconda.sh
source /home/aistudio/miniconda3/bin/activate
conda create --name my_env
conda activate my_env
conda init --all

安装udocker

重新开启一个终端，使用which python确保使用刚安装的miniconda3，接着安装udocker。

# ~/.udocker是无法持久化的，所以创建一个软链接
ln -s ~/external-libraries/.udocker ~/.udocker
python -m pip install udocker

如果配置了代理，通过代理使用udocker install完成安装。没有代理的话，上传udocker-englib.tar.gz，然后通过 export UDOCKER_TARBALL=udocker-englib.tar.gz指定，实现脱机udocker install。

配置udocker环境

如果是GPU环境，可以通过udocker setup --nvidia ubuntu将宿主GPU配置复制到容器内。之前在colab上绘图时试过可用，记得是不需要什么额外设置，飞桨没试。

# 选择focal版本（同宿主），假设配置了代理：
udocker pull --httpproxy=socks5h://127.0.0.1:9050 ubuntu:focal
udocker create --name=ubuntu ubuntu:focal
udocker run --entrypoint=sh ubuntu -c "echo root:root | chpasswd"
# 这步是安装scp，有error无视，也可以从宿主环境复制
udocker run --entrypoint=sh ubuntu -c "apt update"
udocker run --entrypoint=sh ubuntu -c "apt install openssh-client"

# 挂载目录并运行ssh server
udocker run -v /home/aistudio/miniconda3 -v /home/aistudio/external-libraries:/root -p 22122:2222 --entrypoint=sh ubuntu -c "~/handy-sshd --user root:root"

运行时，我将miniconda3直接挂载到容器内，这样容器就不用再安装一遍。同时，我将持久化目录直接当作容器的主目录，这样之前准备的handy-ssh、glider、wstunnel在容器内就可以直接用。

宿主机穿透后，vscode就可以通过ssh连接root:root@HOST:22122，访问udocker内的环境。

此时vscode无法自动找到python，需要在vscode的终端中ln -s /home/aistudio/miniconda3 ~/miniconda3，然后重启vscode，就可以自动发现解释器了。

要注意的是，不能使用 -v /home/aistudio/miniconda3:/root/miniconda3挂载，因为miniconda3在安装后的配置里写死了路径，导致容器内也只认/home/aistudio/miniconda3，这会导致vscode调用时出现混乱。

重启后的环境重建

重启后，非持久化的内容就丢失了，恢复环境需要这些步骤：

# 重新激活 miniconda
source /home/aistudio/miniconda3/bin/activate
conda activate my_env
conda init --all

# 创建软链接
ln -s ~/external-libraries/.udocker ~/.udocker

# 重新建立穿透
cd /home/aistudio/external-libraries
./wstunnel client -R tcp://0.0.0.0:22122:localhost:22122 wss://HOST -P PASSWORD

# 终端新建分屏，开启ssh server

# 无udocker宿主环境
/home/aistudio/external-libraries/handy-sshd --user aistudio:root

# 有udocker的虚拟ROOT环境：
udocker run -v /home/aistudio/miniconda3 -v /home/aistudio/external-libraries:/root -p 22122:2222 --entrypoint=sh ubuntu -c "~/handy-sshd --user root:root"