2025-04-29 14:43:46

引言

今天群里不小小伙伴都表示在访问 GitHub 时遇到了「对本网站的访问受到限制」 (access to this site has been restricted) 、「访问已被限制」(Access has been restricted)的提示。

之前 GitHub 曾因失误部署了屏蔽所有中国 IP 地址的规则，中国 IP 地址访问时会出现禁止访问提示，之后 GitHub 更新了规则，中国 IP 地址重新可以访问了。GitHub 给出的解释当初是部署错误。

如果之前是失误那现在肯定就是故意的了，这次如果你使用代理访问，并且使用的是中文 (仅限 zh_CN)，那么你就有可能被 GitHub 阻止访问。

情况

那么问题来了，GitHub 是打算主动屏蔽所有中国用户吗？
经过我和群内小伙伴们的测试，答案是：应该不是，看起来更像是 GitHub 针对中文爬虫设定的反爬措施。

实际触发这个限制的条件逻辑是：
1. 基于IP或者UA等判断（比如是不是机房IP，代理IP，常见爬虫UA，模拟浏览器头）
2. 基于一些流量模型判断（比如访问频率过高，访问范围过广）
3. 是不是请求头的语言部分包含 zh_CN
4. 只有上边每一层检测，都触发了“是”，那么才会触发访问限制。
5. 并且这个限制是分功能的，不是完全不可用，有可能你可以在浏览器中浏览项目，编辑文件，但你这时却无法在 浏览器内 raw，无法在终端里 git clone。

也就是说，对于正常的中文用户，如果你的IP比较干净，不是使用奇形怪状的浏览器访问，都是可以正常访问 GitHub 的。

碎碎谈

感觉 GitHub 大概率是为了反爬虫、反抓取，毕竟现在 AI 训练爬虫在对 GitHub 疯狂抓取用来训练模型。微软虽然家大业大也没钱了嘛。不过国内爬虫是有多少啊，都能让 GitHub 把语言当作一个过滤条件了。之前那次屏蔽中国IP，搞不好起因也是这个，只是个某个管理错误的把中国的IP段全部给拉黑了。
不过把请求头语言项作为爬虫检查项，意义不大吧，这个特征也不难改……

如果你使用的代理 IP 质量不佳，IP 被万人骑，实在太黑了，导致被 GitHub 拦截了，比较简单的办法就是：
– 换个IP
– 使用一些浏览器请求头修改扩展，将请求头语言部分改成 accept-language = en_US,en;q=0.9,zh;q=0.8 (英语优先，中文备选)。
– 直接去浏览器设置里修改网页首选语言（所有网页都会收到影响，比如不登录状态下谷歌和bing就会给你返回英文网页和英文搜索结果优先了）

以Header Editor 4.1.1 为例，修改请求头

启用请求头修改前，部分位于https://camo.githubusercontent.com的图报HTTP429「Access has been restricted」

启用请求头修改后，马上恢复正常。

The post GitHub 阻止中文用户访问了 吗？(附临时解决方案) appeared first on 秋风于渭水.

2025-04-17 10:05:18

微软明确说明 Windows 11用户在安装4月累积更新（KB5055523）后，不能删除系统创建的“inetpub”文件夹！！如果已经删了，需要按步骤恢复这个“inetpub”文件夹，以提高系统安全性。

最近很多人在安装微软发布的 Windows 11 4月累积更新（KB5055523）后，发现系统C盘根目录下神秘出现了一个名为 “inetpub” 的空文件夹。当时大家一致认为这又是伟大的阿三程序员写出新bug了。

“inetpub” 文件夹通常是微软 Internet 信息服务 (IIS) 创建的，IIS 是微软推出的 Web 服务器软件，用于在Windows 11上托管网站或应用程序，一般情况下只有在启用 IIS 后根目录才会出现 “inetpub” 文件夹，但在此次更新中，即使用户未启用 IIS 该文件夹也会自动创建。看起来十分不正常，于是大家都认为这是个 bug。

于是很多科技博主都表示 “这个 “inetpub” 文件夹可以删除，本身这个文件夹也是空的，测试删除后不会对系统造成任何负面影响”，我也受不了C盘有个陌生文件夹，就给删了，结果尴尬了……

但其实这个操作是为了修复漏洞“CVE-2025-21204”的，估计微软没想到大家会如此在意系统根目录出现陌生文件夹，在更新日志中压根没提到会有这个操作，考虑到用户删除“inetpub”后会影响系统安全，微软最近又更新日志添加了这个文件夹的说明。

注意：直接手动重建这个文件夹对修复漏洞“CVE-2025-21204”是没有作用的！需要按正确步骤恢复

恢复方式一：
1. 点开开始菜单
2. 在搜索框里搜索开启或关闭 Windows 功能并打开
3. 勾选 IIS 服务 (Internet Information Services) 并点击确定
4. 等待 1、2 分钟 IIS 服务会完成安装，此时会自动创建“inetpub”文件夹
5. 随后关闭 IIS 服务

恢复方式二（微软的推荐做法）：
1. 设置 → Windows更新 → 更新历史记录
2. 拉到底，选「卸载更新」
3. 找到 「用于Microsoft Windows的安全更新（KB5055523）」，点击卸载，等待卸载完毕后，重启电脑
4. 重启后，再次检查系统更新，并重新安装「适用于 Windows 11 Version 24H2 的 04 累积更新，适合基于 x64 的系统 (KB5055523)」即可自动恢复“inetpub”文件夹。

The post WIN11更新后，C盘下莫名多出的神秘空文件夹inetpub不是BUG，不要删 appeared first on 秋风于渭水.

2025-04-16 15:20:54

Claw Cloud Run是 Claw Cloud 旗下的轻应用平台，你可以理解成 Vercel、Netlify 之类的东西，既是 PaaS 平台，也有 Serverless 服务，还能跑类 Docker 项目（不是直接用 Docker 跑的，是自动适配，用 Serverless 形式跑的），可以快速部署 Alist、Rsshub、Memos、Uptime Kuma、Chatgpt-next-web等程序。甚至可以用来跑 Minecraft 游戏服务器，注册即送 5 刀额度，如果绑定一个注册超过180天的 Github 账号可以永久享受每月5美元的额度。每个可用区有4H 8G 10G 资源，一共 10 GB 流量。

有白嫖自然是很开心的嘛，虽然Vercel也挺好用的，但是Claw Cloud Run还有免费的数据库可用，跑一些个人项目会更加方便一点，最主要是，新加坡区和日本区到国内的速度相当不错：

注册页链接 (有AFF)

如果不想走我的AFF的话，自己谷歌一下「Claw Cloud Run」就能找到官网了。

使用注册超过180天的github账号登录的话，可以享受每月5刀的赠送，不需要信用卡。
如果没有的话，则只会赠送一次5刀的额度。

注意：每月送的5刀的账户，还是免费计划而不是爱好计划。送你的5刀是让你抵扣使用费用的。
根据页面上的预计费用，Alist 每天0.04刀，WordPress 每天0.06刀，通过适当自行缩小容器配置，算下来每个月免费部署4、5个自用项目还是没问题。

如何缩小容器配置

默认他一个项目最小给1H1G，对于有些小项目，实在太奢侈了，适当改小可以有效降低部署费用。
我有个给贴吧自动签到的脚本，这玩意本地跑才占用几M好不，所以我只给了0.1核64M内存。每天仅需1分钱（其实用不到的，只是因为显示上最小差值是 0.01元）。

1. 进入应用列表
2. 点进需要修改的项目
3. 左上角有个「Update」，点进去
4. 愉快的把CPU和内存改小就好了。

PS： Claw Cloud（阿爪云，又名阿里云青春版）小道消息称，这是阿里云在新加坡开的马甲（因为他们基础设施都是用的阿里云的）。不过也有一种可能是基于阿里云的二道贩子在蹭热度，这在云服务提供商中也并不少见。

友情提醒
1. 目前 Claw Cloud 的 Janpan 和 Singapore 非常拥挤，随便一个项目开机都要好几分钟，请尽量避开日本和新加坡区。
2. 他家服务稳定性比较，嗯，最近可能人多，有点炸裂，如果项目出问题了，请重启项目解决。

The post Claw Cloud Run 免费容器来了，无需信用卡，Github账号满180天，终身每月送5$ appeared first on 秋风于渭水.

2025-03-23 11:47:56

我也没开广告拦截收入挽回啊，谷歌就偷偷通过扩展静默注入广告拦截收入挽回代码了？
我对大家拦截站内广告的态度是：不喜欢看那就拦截掉，不想看广告是用户的权利。

开始我还以为谷歌这是广告营收下滑了，着急了。
结果去查了一下。啥，营收反而涨了？
哦，不会就是靠这种方式涨的吧

随后我再仔细一看，好嘛
反反广告拦截收入挽回也被自动注入了
去广告拦截器拦截了广告拦截收入挽回会被检测

但问题是，我压根就没开这个功能，adsense 内这个选项也是关闭状态，这完全是谷歌自作主张自行强制加入的。

从“不作恶”到“做正确的事”
从“技术导向”到“资本导向”
谷歌公司正在向下一个波音公司一路狂奔……

The post 谷歌这是在干啥？强制给我开个广告拦截收入挽回？ appeared first on 秋风于渭水.

2025-03-19 20:20:36

为了解决几十万量级图片库内异常图片的检测，折腾出了一个基于 python 的图片检测程序。

一、混乱的图片仓库

用前一段发现的本地 AI 图片视频搜索引擎 MaterialSearch 整理十几年间积累的几十万张图片时，遇到了一个令人崩溃的场景：有上百张图片报损坏，经过部分核查，很多文件打开后呈现诡异色块，亦或者只有半截图，还有些文件大小为 0 KB。这些损坏的图片零散的散布在数千个子文件夹中，手动一个一个检查无异于大海捞针，累死也搞不定。于是 VS code 启动！！

二、初版方案

用 Pillow 暴力验证，直接用 Pillow verify()看看是否报错来解决。

代码V1.0方案（基础检测逻辑）

from PIL import Image

def check_img_v1(path):
    try:
        Image.open(path).verify()
        return True
    except:
        return False

V1.0方案的情况：
1. 误报文件：很多图片会报损坏，但是用图片浏览器打开却十分正常，经过研究之后才知道，原来大量网站在使用一种叫做渐进式JPEG的技术，通过将图像数据分为多个扫描逐层渲染，可以在网速不好时图片先绘制出低分辨率的模糊轮廓，随着数据被下载逐步变为清晰图像（现代图片编码如WEBP、AVIF也都有类似的渐进式加载机制）。这导致需要完整解码才能验证所有扫描数据。因此被verify()误认为损坏。
2. 漏检文件：未完整下载的图片有时也能通过验证。
3. 性能问题：慢，按照测试计算，10万张图片的检测起码需要耗时4、5小时了。

三、改进方案

经过对 MaterialSearch 日志报错图片的抽查，发现损坏的文件主要是文件不完整导致的半截图，于是我打算改为：先检查文件结尾是否存在结束符来判定图片是否损坏，然后再做进一步检查。

代码V2.0（尾部校验部分代码）

def check_img_v2(path):
    with open(path, 'rb') as f:
        f.seek(-32, 2) #只用获取文件最后32字节就行
        trailer = f.read()
        if path.lower().endswith('.jpg'):
            return trailer.endswith(b'\xff\xd9')  # JPEG的结束符
        elif path.lower().endswith('.png'):
            return trailer.endswith(b'\xaeB`\x82')  # PNG的IEND块

V2.0方案的情况：
1. 捕获到了异常文件 ：下载一半的文件确实被检测出来了。
2. 检测了个寂寞 ：如果图片附加了元数据，图片文件很可能就不是以\xff\xd9结尾了，结果就是1000张的测试图片，在尾部检测部分逻辑，有800多张都报了损坏……想快速检查了个寂寞。

四、再次优化

使用img.load() 强制加载所有数据。对渐进式jpeg图片做特殊处理逻辑。

代码V3.0（验证部分的修改）

def check_img_v3(path):
    try:
        with open(path, 'rb') as f:  
            img = Image.open(f)
            img.load()  # 强制加载完整图片

            # 特殊处理渐进式JPEG
            if img.format == 'JPEG' and 'progressive' in img.info:
                img.tile = []  

            return True
    except Exception as e:
        print(f"损坏文件: {path} | 错误类型: {type(e).__name__}")
        return False

V3.0方案的情况：
1. 漏报率下降了很多
2. 渐进式JPEG兼容处理
3. 打印异常类型方便处理
4. 实际代码中自己傻逼了在verify()之后调用load()，导致文件指针不可用，说人话就是：代码逻辑中verify()做完检查后，就把图片文件关闭了，load()啥也获取不到。
5. 性能就很一般了，基本和初版差不多的速度。

五、终局之战

又经过一番研究和查证其实 Pillow verify()对渐进式图片检测是没问题的，误报率并没有我在V1测试时那么高，只是我本地环境的 Pillow 版本不够新而已，但也确实会有漏报。只用load()也会有漏报，有一点误报可以接受，但是漏报就无法接受了，所以还是需要联合检查。

最终决定采用如下逻辑
1. 先检测文件路径是否存在，收集所有路径。
2. img.verify()先上
3. 同一个循环内使用img.load()再来一次检测
4. 并行处理加快处理速度
5. 不在控制台显示扫描 log，毕竟绝大部分图片都是好的，没问题的显示出来无意义，只显示有问题的又很容易看起来像是卡住了，所以用 tqdm 做个进度条。还能大概估计下完成时间。
6. 用 jinja2 做个 html 格式的检测报告，毕竟在终端里复制粘贴起来也不方便。

代码V4.0（完善使用）

实在太长了就放github上了：img_validator.py

命令：python img_validator.py <"目录路径"> [并发数]

ex:python img_validator.py "D:\Download\图片" 8

最终会在脚本的同级目录下生成 html 格式的检测报告image_validation_report.html

• 路径最好用””框住
• 并发数可以不填，默认使用CPU全部线程。除非你用非常大的图，不然全线程跑也费不了多少CPU占用。
• 理论上 10W 张图片在 12 线程下，用时应该半小时都不到，不过实际上受制于仓库盘使用的是 HDD 只能到 20~40files/s，机械硬盘的读出速度跟不上检测速度，特别是到最后20%的时候，速度更是掉到只有个位数了。18W 张图片的文件夹，检测用时接近5个小时，平均速度 ≈ 11 files/s
  
• windows 和 unix 系统都可用，代码会自动处理两者的路径差异。

为什么会有这么多图片损坏

自己十年前写的P站抓取代码不完善，如果因为网络超时导致图片下载失败，爬虫会重试，但是之前损坏的图片有可能并不会被正确清除（删除部分代码没有正确处理超长文件名和带特殊符号的文件名），虽然带问题代码只使用了从14年到16年这大约一坤年，但是也积累了接近 600 张问题文件。不过倒是挺奇怪的，抓全年龄的部分出现大量这种问题，抓R18的几乎就没出错过，这是又为什么呢，沉思中…………

The post 如何快速批量检索损坏的图片文件—python开发学习笔记（一） appeared first on 秋风于渭水.

2025-03-12 18:06:17

收集自网络，结合自身体验得出，虽然我更多是用的自己的 DeepSeek API，但是 R1 这种思考时，一个不想小心就能想个几千字的玩法，也是有点扛不住，复杂问题还是先找免费的问的差不多了，再用自己的 API 增加体验。毕竟白嫖总是让人开心。

DeepSeek R1 可免费/白嫖网页版一览

The post DeepSeek R1 可免费/白嫖网页版一览 appeared first on 秋风于渭水.