@tavimori #2
@wd #3

如#1 所说，这样的话 TCP 不通，而 UDP 是能收到的，但 UDP 只要用 SNAT 改变了源 IP ，客户端收到后就不知道该往哪发了

altstore

想起一张网络图片，“转让网恋对象，偶尔会给你点外卖发红包，我拿小号聊的，可以直接接手继续聊不会露馅”

不会，你这样不算滥用，但其实 github actions 没有那么准时，还经常宕机，你可以看看 Cloudflare Workers 的 Cron Triggers 。

这有个可能比较完善的实现

https://v2ex.com/t/849156#r_11602856

https://github.com/nadoo/glider/tree/401efd621aeecc8804b05b43208e52d5460f3b7b/pkg/sockopt

https://github.com/nadoo/glider/blob/401efd621aeecc8804b05b43208e52d5460f3b7b/proxy/direct.go#L80-L108

超声波+眼镜布

@wangyu17455 #1 场景比较特殊，fwmark+ip rule 不太灵活，权限要求也高一些。

@zeusho871 #3 按照官方 issues 里有人指出的，大约是因为仅仅指定 LocalAddr 后依然会按照默认的路由策略走，所以在这种场景没办法达到想要的效果。

#2 的是和 curl --interface 相同的处理方式，测试了 UDP 和 TCP 在 Linux 下都没问题。

@cs8425 #2 谢谢，正打算看 curl 实现，被你拯救了~

我的是 65W 的，努比亚和倍思正常使用了很久，最近考虑入 Aohi 或者 anker 的超级小的单口 65W 。

经常看到一些老外大牛会把“是妻子的丈夫，是子女的父亲”这样的话写在个人简介的最前面（不过真的很少看到他们写“是父母的儿子”，不知道算不算文化差异）

#2 #3 OP 说的 command 补全和 shell 补全应该是不一样的。

类似于
$ openssl ran
补全 rand ，这是 shell

$ openssl
> ran
这类补全我一直以为是程序处理的

感觉龙芯笔记本挺贵的

公开频道可以通过 t.me/s/<name> 访问

@0o0O0o0O0o 成本感觉太高了，我也想知道它能撑多久…

成本

@mercury233 有时候删分支和重写提交也未必有用，尤其是中间还有一层 GitHub ，还是新建个比较好

例如 CVE-2022-24975

secrets ，但对你的历史提交无效。嫌麻烦就让 API Key 和别的信息失效，或者修改代码后 rm -rf .git 重新初始化，重新创建一个 public repo ，后者更安全。

https://developers.cloudflare.com/workers/platform/cron-triggers/

我一般用这个

既然你说的是公司，那这一般叫自然人独资，只是在老人在世期间用来给你自己缴社保是没什么问题的，但你在#2 提到的那些操作有点太孝了。