mihomo(clash) 无法访问 raw.githubusercontent.com 的解决方案

2024 2 27 12:24 PM 0 条评论 574 次查看

分类：无 标签：翻墙

前几天在使用 brew 安装 im-select 时发现从 raw.githubusercontent.com 下载失败了，而 brew 是用 curl 下载的，我已经在 ~/.curlrc 里配置了 socks5 = "127.0.0.1:1080"，理论上它应该走本地代理，怎么会失败呢？
于是我直接执行 curl 看看：
curl -v https://raw.githubusercontent.com/daipeihust/im-select/master/macOS/out/apple/im-select
*   Trying 127.0.0.1:1080...
* Connected to 127.0.0.1 (127.0.0.1) port 1080
* Host raw.githubusercontent.com:443 was resolved.
* IPv6: (none)
* IPv4: 0.0.0.0
* SOCKS5 connect to 0.0.0.0:443 (locally resolved)
居然在本地解析成 0.0.0.0 了，这不是应该走代理去解析的吗？

都 2024 年了，该更新翻墙技术了

2024 1 12 11:51 PM 5 条评论 10135 次查看

分类：无 标签：翻墙

时光荏苒，距初代的翻墙神器 shadowsocks 停更都已过去 6 年了，这期间墙早已进化了多次，至少原生的 shadowsocks 基本上会被秒封了。
随着墙的进化，我翻墙的姿势也不得更换了数次，使用最久的还是 kcptun + shadowsocks 的方案，毕竟对于线路不好的 VPS 而言，可以自定义拥塞控制的 UDP 协议还是比 TCP 快几个数量级的。
不过最近两年 kcptun 也容易被墙了，于是我又开始了新的寻觅，然后选中了 hysteria。它被墙的概率要低很多，而且无需配合 shadowsocks 等协议一起工作，可以直接提供 SOCKS5 和 HTTP 代理。

用 nginx 对文件服务器鉴权

2023 11 21 12:35 PM 0 条评论 240 次查看

分类：Web 标签：nginx

最近项目中遇到一个需求：
用户在使用 seafile 上传文件，希望将其分享出去。
seafile 自己生成的分享链接类似于 https://seafile.xxx.com/f/23cc6812408e44f8b63e/，若未过期且密码正确时会将其重定向到类似 http://seafile.yizhisec.com/seafhttp/files/e1687864-8a12-46db-9708-b4240df346be/1.txt 的地址。
产品希望能对这个分享链接进行鉴权，并且最好不暴露实际的文件地址和避免发起重定向的请求。

把任务队列 delayed 移植到 Go 了

2023 3 24 05:22 PM 0 条评论 195 次查看

分类：Go 标签：Go

4 年前我用 Python 写了个叫 delayed 的任务队列，经过几年发展后，公司有了 Go 和 Python 相互调用的需求。
目前的 delayed 实现是用 pickle 来做序列化的，其实之前也写过用 JSON 来做序列化的版本，但是遇到了几个问题：
  1. JSON 会丢失一些对象类型，例如无法区分 tuple 和 list。
  2. JSON 无法直接编码二进制字符串（bytes）。
  3. JSON 不支持原本 pickle 能支持的很多类型。
当时因为这些问题我就放弃了，但是现在看来，这些问题有的可以解决，有的可以容忍，所以还是决定开发 Go 的版本。

换个域名

2022 11 3 04:43 PM 1 条评论 321 次查看

分类：无 标签：无

正如关于本站被墙的一些分析一文中所说，keakon.net 这个用了 12 年的域名被墙了。
我也懒得再费劲买域名与墙对着干了，就注册一些免费的域名轮流换吧，墙了也不心疼。好像那些不可描述的网站也是这样干的？

sync.Map 不是线程安全的？

2022 10 26 12:35 PM 0 条评论 220 次查看

分类：Go 标签：Go

昨天在压测公司的项目时发现，sync.(*Map).Store() 抛了个异常，日志如下：
fatal error: sync: unlock of unlocked mutex

goroutine 63756060 [running]:
runtime.throw({0xbeeca9, 0xb45120})
#011/usr/local/go/src/runtime/panic.go:1198 +0x71 fp=0xc0010f13a0 sp=0xc0010f1370 pc=0x4336d1
sync.throw({0xbeeca9, 0xb2dd40})
#011/usr/local/go/src/runtime/panic.go:1184 +0x1e fp=0xc0010f13c0 sp=0xc0010f13a0 pc=0x45ecfe
sync.(*Mutex).unlockSlow(0x11d45a0, 0xffffffff)
#011/usr/local/go/src/sync/mutex.go:196 +0x3c fp=0xc0010f13e8 sp=0xc0010f13c0 pc=0x47851c
sync.(*Mutex).Unlock(...)
#011/usr/local/go/src/sync/mutex.go:190
sync.(*Map).Store(0x11d45a0, {0xae4960, 0xc0012f4350}, {0xae40e0, 0xc000026078})
#011/usr/local/go/src/sync/map.go:163 +0x465 fp=0xc0010f1480 sp=0xc0010f13e8 pc=0x476fa5
要知道这可是 Go 的官方库，sync.Map 可是专门为并发安全而设计的，难道直接调用它的接口也会出现线程冲突？

Docker 镜像拼接技术

2022 9 11 06:19 PM 2 条评论 276 次查看

分类：Docker 标签：Docker

公司的服务是 Docker 搭建的，给客户升级时存在一个问题：镜像太大了。
虽然我已经找了很多方法，甚至对于 Go 服务而言，已经全换成 scratch 镜像 + 单可执行文件的方式了，但是对于 Python 服务却没啥办法。大部分的 Python 库是有 C 库依赖的，因此不能用 scratch 镜像，甚至因为 alphine 镜像不是用 libc，也会出现很多兼容性问题。而在 Ubuntu 的基础上安装完依赖后，就轻松超过 300 MB 了。
因为不能在客户那搭建一个 docker repository 把镜像推过去，那只能想些奇技淫巧来实现了。

« 看看还有什么好玩意