tes286 最近的时间轴更新 tes286 最近的时间轴更新
TES286
tes286 最近回复了
2025 年 12 月 4 日 回复了 zyxk 创建的主题 程序员 webview2 (wails) 应用真的比 electron 应用更省内存吗？但似乎不是这样， 实测: Windows 任务管理器骗了你！ |
@ku9527 360 自己都是流氓头子有什么资格说别人。
实际上这是一个很常见的做法。不少开源软件都是后台进程+webui 的模式。比如我电脑上正在跑的 Sunshine ，Jellyfin 。除此之外，你还可以找到一大堆类似做法的软件。它们有什么问题？
不过感觉是更好的做法是，webui 的静态资源在线托管，用 service worker 缓存，然后本地只开一个 API 接口，QQ 登录的识别本机已登录账号就是类似的做法，但是这样要考虑 mixed content 问题，可能要给本地安装一个自签名证书。
实际上这是一个很常见的做法。不少开源软件都是后台进程+webui 的模式。比如我电脑上正在跑的 Sunshine ，Jellyfin 。除此之外，你还可以找到一大堆类似做法的软件。它们有什么问题？
不过感觉是更好的做法是，webui 的静态资源在线托管，用 service worker 缓存，然后本地只开一个 API 接口，QQ 登录的识别本机已登录账号就是类似的做法，但是这样要考虑 mixed content 问题，可能要给本地安装一个自签名证书。
2025 年 11 月 18 日 回复了 Features 创建的主题 全球工单系统 活久见， Cloudflare 香港崩了 |
现在控制台能上，但是完全操作不了，api 请求一直 503 。不过我自己的站正常了，至少访问来看完全没问题，不过感觉延迟高了一点。
2025 年 11 月 16 日 回复了 dark495 创建的主题 宽带症候群 [后续 5] 我申请福建通信管理局公开对泉州联通的责令整改内容，结果来了 |
加油，好样的。
就是要硬刚，不能让他们过的太滋润了
就是要硬刚，不能让他们过的太滋润了
2025 年 10 月 13 日 回复了 EasyLink 创建的主题 VPS [重大更新] VMRACK 正式上架 CN2 三网精品线路，极速网络体验等你来！抽两台三网精品年鸡！ |
VMRACK 上新 cn2 三网精品线路
2025 年 10 月 4 日 回复了 dididi9527 创建的主题 iCloud 广东电信对阿里云的 DNS 解析会影响 iCloud 的备份 |
@rzbb 好像确实不一样？实际解析出来 ip 的线路不同。
这里是湖北移动，解析 alibaba-cn-pvg-00001.oss-cn-shanghai.aliyuncs.com ，从 4.2.2.1 获取的 ip 地址为 47.101.9.7 ，从 223.5.5.5,8.8.8.8 ，cloudflare doh 获取的都是 183.192.187.127 。而关闭 edns client subnet 后一律是 47.101.9.7
前者是阿里云多线地址（ AS37963 ），后者是中移上海公司的地址（ AS24400,AS9808 ）
猜测为阿里为了省钱，根据源 ip 分流到差的线路，但是差线路实在是太差了，又或者是没做好优化。而没有 edns 提供客户端信息后，fallback 回更好的线路。
解决方案是用没有 edns 的 dns ，或者有部署本地 dns 的，试一下单独给*.oss-cn-shanghai.aliyuncs.com 配置规则
这里是湖北移动，解析 alibaba-cn-pvg-00001.oss-cn-shanghai.aliyuncs.com ，从 4.2.2.1 获取的 ip 地址为 47.101.9.7 ，从 223.5.5.5,8.8.8.8 ，cloudflare doh 获取的都是 183.192.187.127 。而关闭 edns client subnet 后一律是 47.101.9.7
前者是阿里云多线地址（ AS37963 ），后者是中移上海公司的地址（ AS24400,AS9808 ）
猜测为阿里为了省钱，根据源 ip 分流到差的线路，但是差线路实在是太差了，又或者是没做好优化。而没有 edns 提供客户端信息后，fallback 回更好的线路。
解决方案是用没有 edns 的 dns ，或者有部署本地 dns 的，试一下单独给*.oss-cn-shanghai.aliyuncs.com 配置规则
2025 年 9 月 22 日 回复了 JustBeFree 创建的主题 DNS 目前在 Chrome 安全 DNS 中选择 Cloudflare 作为 DNS 提供商所遇到的一些问题 |
https://www.cloudflare.com/zh-cn/learning/ssl/what-is-encrypted-sni/
大概是 esni 发力了。esni 需要 https 类型 dns 记录，国内的 local-dns 大概会过滤掉。只是 sni 阻断的网站当然就能联通了。
不过这个方法不太稳定，也支持有限（目前仅观察到 cloudflare 大量部署了 esni ，也就是只能连到 cloudflare 上的网站，并且网站所有者没关掉这个功能），且需客户端支持。
观察 https://<domain>/cdn-cgi/trace 中的 sni 字段，一般是 sni=plaintext 或者 sni=encrypted ，分别对应 esni 是否启用。
大概是 esni 发力了。esni 需要 https 类型 dns 记录，国内的 local-dns 大概会过滤掉。只是 sni 阻断的网站当然就能联通了。
不过这个方法不太稳定，也支持有限（目前仅观察到 cloudflare 大量部署了 esni ，也就是只能连到 cloudflare 上的网站，并且网站所有者没关掉这个功能），且需客户端支持。
观察 https://<domain>/cdn-cgi/trace 中的 sni 字段，一般是 sni=plaintext 或者 sni=encrypted ，分别对应 esni 是否启用。
2025 年 9 月 12 日 回复了 bugly 创建的主题 程序员 一次 XML 上传导致域名被封的经历复盘（腾讯网址安全中心是不是只剩下机器人了） |
嗯，调用 oss 资源没有签名吗，有签名也不会被黑产引导直接访问链接吧（时效限制）。
还有一些其他的措施，可以缓解，比如加上 Referer 限制，强制将 Content-Type 设置为 application/octet-stream 和 x-content-type-options 为 nosniff ，可以部分缓解该情况。
还有一些法子，应该有用但是不太常规。比如，存图片到 oss 时，先加密，然后展示时前端解密。不用太复杂，也没必要藏密钥。总之就是让器人识别不出这是什么东西。用 xor 就可以（虽然可能绕过，但是足够应对非针对性的攻击）。
不过最好还是别允许 svg 了吧。
还有一些其他的措施，可以缓解，比如加上 Referer 限制，强制将 Content-Type 设置为 application/octet-stream 和 x-content-type-options 为 nosniff ，可以部分缓解该情况。
还有一些法子，应该有用但是不太常规。比如，存图片到 oss 时，先加密，然后展示时前端解密。不用太复杂，也没必要藏密钥。总之就是让器人识别不出这是什么东西。用 xor 就可以（虽然可能绕过，但是足够应对非针对性的攻击）。
不过最好还是别允许 svg 了吧。
2025 年 7 月 30 日 回复了 xieranmaya 创建的主题 程序员 为什么永远有人在一谈到计算机/编程就要说自学呢？为什么？ |
先不讨论别的，就是说，以我的经验（我是自学的），有自学能力的人解决问题的能力强，不容易给人添麻烦
我遇到过有些人，习惯了老师带着，看到问题，首先去问，“这个怎么办”，“为什么现在又不行了”，“怎么打不开”
而可以自己探索的人，往往会自己尝试解决，实在没辙才会提出问题，比如在提 issue 时，附加上：
- 错误追踪
- 日志
- 版本
- 可能的原因分析
- 等等
我没有权利要求每个人都必须做到这些要求，但社区对于傻瓜式的提问明显是不太高兴的，因为大家不是淘宝客服
有一些老话，就反应了这点，比如 no code no fix ，又比如名言 read the fucking manual （ RTFM ） 和 search the fucking web （ STFW ）, 都是一个潜规则，尊重他人时间，先自助再求助。纯粹从培训班出来的人恐怕没有多少知道这些的。
久而久之，人们就倾向于让人们自学，也是在设置一个门槛，变相也是在为自己省事。没错，我们希望*宁缺毋滥*，大批的人的涌入并不总是好事。如果不信，翻一翻 GitHub 里热门仓库的 issues ，说不定还能找到亮眼的，一大堆英文中的中文，问着傻瓜式的问题（可能是我见识浅薄，GitHub 中最常见的语言一是英文，二就是中文。其他语言要么是项目本身有本地化才有，要么就没有）
反正，投入精力研究的习惯与能力是必须的，当然啦，如果你可以教给你的学生这些，那就最好了。推荐读物：《提问的智慧》
我遇到过有些人，习惯了老师带着，看到问题，首先去问，“这个怎么办”，“为什么现在又不行了”，“怎么打不开”
而可以自己探索的人，往往会自己尝试解决，实在没辙才会提出问题，比如在提 issue 时，附加上：
- 错误追踪
- 日志
- 版本
- 可能的原因分析
- 等等
我没有权利要求每个人都必须做到这些要求，但社区对于傻瓜式的提问明显是不太高兴的，因为大家不是淘宝客服
有一些老话，就反应了这点，比如 no code no fix ，又比如名言 read the fucking manual （ RTFM ） 和 search the fucking web （ STFW ）, 都是一个潜规则，尊重他人时间，先自助再求助。纯粹从培训班出来的人恐怕没有多少知道这些的。
久而久之，人们就倾向于让人们自学，也是在设置一个门槛，变相也是在为自己省事。没错，我们希望*宁缺毋滥*，大批的人的涌入并不总是好事。如果不信，翻一翻 GitHub 里热门仓库的 issues ，说不定还能找到亮眼的，一大堆英文中的中文，问着傻瓜式的问题（可能是我见识浅薄，GitHub 中最常见的语言一是英文，二就是中文。其他语言要么是项目本身有本地化才有，要么就没有）
反正，投入精力研究的习惯与能力是必须的，当然啦，如果你可以教给你的学生这些，那就最好了。推荐读物：《提问的智慧》
2025 年 1 月 5 日 回复了 BeijingBaby 创建的主题 云计算 今天才知道：阿里云域名是不能 [随意跳转到第 3 方网站] 的 |
Select Language