CC攻击事件报告 20250613至20250619

过程和初步评价

发生于 2025-06-13 23点 左右短期，当时很快就结束了，有收到CF的邮件通知但是当时并未理会。

第二天 2025-06-14 23点 至 2025-06-15 23点 左右，持续了整整一天的 CC 攻击。

• 攻击特征:
  • 第一波攻击固定路径，第二波攻击另一个固定路径。
  • 均为固定路径，无参数，无随机路径。
  • User-Agent (UA) 较多。
• 攻击影响:
  • 反向代理服务器略有卡顿。
  • 后端服务器满载。
• 流量分析:
  • UA 种类繁多，国内 IP 特别多，国外 IP 也不少。
  • CC 攻击量不小，规模上看使用了至少几千个代理 IP，其中国内 IP 都有 2000+。
  • 2025-06-14 单日 (Cloudflare 统计):
    • 独立访问者: 27.5K
    • 流量: 14TB
    • 请求数: 58.81M
  • 2025-06-15 单日 (Cloudflare 统计):
    • 独立访问者: 48.8K
    • 流量: 28TB
    • 请求数: 106.06M

后续发现是 Cloudflare 的页面规则当时设置的没缓存成功这个路径，最后通过 CDN 强制缓存控制后，问题基本解决，绝大部分请求都已缓存。

样本抽取

抽取了以下几种场景样本：

• 表A: 06-15 中国大陆IP (CF自动抽样20%)
• 表B: 06-15 全球IP (CF自动抽样20%)
• 表C: 06-15 抽样百万大陆IP (通过国家盾/ASN盾/IP盾)
• 表D: 06-15 抽样百万全球IP (通过国家盾/ASN盾/IP盾)
• 表E: 06-14-06-15 抽样七百万全球IP (全部样本)

注：随着攻击持续，国家盾/ASN盾/IP盾在持续迭代，所以有的会从“通过”变成“未通过”。

第三波攻击

第三波攻击发生在 2025-06-18 23点 至 2025-06-19 03点 左右，这时我事先额外加上了阿里CDN。

• 防御架构: 国内由 CF CDN + 阿里CDN + 反代节点 一起抵御。
• 过程: 发现反代节点跑了 0.5C 左右的资源，但因持续产生流量遂将其掐掉，让阿里和CF来抵御。
• 数据统计:
  • Cloudflare (2025-06-18):
    • 独立访问者: 12.98K
    • 流量: 3TB
    • 请求数: 24.62M
  • 阿里云 (同期):
    • 请求数: 55.47M
    • 客户端请求流量: 27GB
    • EdgeStart 响应流量: 253GB

样本抽取 (第三波)

• 表F: 06-18-06-19 抽样75万大陆IP (通过国家盾/ASN盾/IP盾)
• 表G: 06-18-06-19 抽样万全球IP (全部样本)

目前审计几个样本表后得到了 5,247个中国IP（总量23,656个IP），是目前遇到国内来源最多的一次攻击，说明攻击者在肉鸡资源上实力不俗。

IP 统计已发布在: https://github.com/BlueSkyXN/Comprehensive-Network-Defense/blob/master/IPs/IPs_CCATK-20250614-0619.csv

防御策略

防御策略上，重点在于 Cloudflare 规则，其次阿里 CDN 套娃 CF 还能双重防御，后面其实还可以接宝塔 NGINX 和雷池。

Cloudflare 防御

首先重点肯定是大善人 CF 了，CF 的设置项目非常多。整体来说包括：缓存规则、自定义规则（原WAF规则）、速率限制规则、安全级别、自定义列表、IP和ASN访问规则。

缓存规则

这是一个比较重要的点，无论是日常使用还是防止简单 CC 都有很好的效果。免费用户可以设置 10 条缓存规则。

1. 缓存级别:
   • 忽略缓存控制标头，使用此 TTL (例如设置为2小时): 这个选项可以强制缓存那些服务器标记为动态但实际内容不变的页面 (除非你需要很多真实动态内容)。
2. 缓存密钥:
   • 缓存欺骗盔甲: 开启。
   • 按设备类型缓存: 可开，如果攻击 UA 大量随机化，可能需要关闭。
   • 忽略查询字符串: 可选开启，如果对方进行随机查询字符串攻击则需要开启。
   • 查询字符串排序: 建议开启。
3. 其他:
   • 重新验证时提供过时内容: 设置为“否”。
   • 源服务器错误页面通过: 设置为“否”。

自定义规则 (原WAF规则)

免费用户可以设置 5 条自定义规则。这是高级表达式发挥作用的地方。

• 参考配置: https://github.com/BlueSkyXN/Comprehensive-Network-Defense/blob/master/CF/cf-def.txt
• 逻辑上包括:
  1. 允许规则 (Allow): 跳过自定义规则、浏览器检查、托管规则等 (但不建议跳过速率限制)。用于放行反代、爬虫、API 等可信的 UA/ASN/IP/路径。
  2. 拦截规则 (Challenge/Block): 对特定的 ASN、国家、请求方法、URL路径和黑名单IP列表等进行混合拦截或质询。
  3. 日志记录规则 (Log): 和拦截规则反过来写，方便记录日志。比如记录来自哪些国家/ASN/地址的请求，操作设置为“跳过”部分规则 (如区域锁定) 但不执行拦截。
• 日志拉取脚本: https://github.com/BlueSkyXN/Comprehensive-Network-Defense/blob/master/Scripts/cf_waf_collector.py

速率限制规则

免费用户只能设置 1 条。由于限制，只能当作全局限制来用，例如单IP在10秒内请求超过100次则封禁10秒。

安全级别

遭遇攻击时开启“我正在受到攻击”模式即可。

自定义列表

免费用户只能创建 1 个自定义列表，但支持多达 10,000 个条目，支持 IPv4/IPv6 和 CIDR。可以和国家、ASN 盾配合使用（在自定义规则中调用它）。

• IP 列表参考: https://github.com/BlueSkyXN/Comprehensive-Network-Defense/blob/master/IPs/SKY-CF-IPLIST.txt
• 列表清空脚本: https://github.com/BlueSkyXN/Comprehensive-Network-Defense/blob/master/Scripts/cf-clear-custom-list.py

IP和ASN访问规则

免费用户支持 50,000 条规则，优先级较高，对全账户通用。支持 IPv4/IPv6、CIDR、ASN 和国家。但手动只能一条一条添加，且日志记录不全。

阿里 CDN 防御

目前国际站免费，有不少限制但是够用。内置了负载均衡池等功能，适合套娃 CF。

WAF - 智能限频

藏得比较深，是一个高级的速率限制规则。位于“安全防护”->“WAF”的最下面。可以设置高、中、低防护等级（默认对应10秒内4000/200/40次请求），可选开启 JS 挑战。

WAF - IP访问规则

只能添加 200 条，不是很有用。

WAF - 自定义规则

免费 3 条，可选开启 JS 挑战。匹配规则与 CF 类似，但 IP/ASN 等可以使用“分组”功能，每个分组支持 500 条，免费用户可创建 10 个分组。

规则 - 缓存规则

免费 10 条，逻辑上和 CF 一样，要覆盖源站（除非你需要很多真实动态内容）。

规则 - 安全规则

免费 2 条，与上面的自定义规则不同，结果只能是修改安全级别（最高就是 CF 的“正在攻击”模式），可应用 IP 组等。

最近入手了一台天蓝色MacbookAir M4 13寸 24+512版，耗资7931CNY，目前使用一周，谈谈体验

存储方面

我买的是512G版，外接硬盘的话基本没用上，我实测把日常的东西都装上后（比如Office/VScode/Feishu等），发现还没用到100G，表现和iOS有点类似。当然，我基本是不怎么用微信的所以微信并不大。

内存方面

我买的是24G版，我发现系统日常基本都能控制在16G左右的内存用量，这个处理逻辑看上去和安卓挺类似，并不会很容易用满，根据内存记录来看基本是够用的，只需要你别开太多的浏览器TAB。

续航方面

功耗确实非常惊艳，外接5K60Hz显示器+5Gbps USB固态+内屏开启的情况下，整机功耗在10-12W这样，合盖/关闭内屏后可达3-5W，表现略高于安卓平板。还没遇到过能大于30W的场景，没想到官方配的35W充电器是完全够用的。
电池上比13寸安卓平板略大，但是功耗看上去更高，我不认为对比安卓平板有续航优势，但是比传统笔记本肯定好得多了。但是不知道为什么都M4了还没给自定义充电电量上限啊，iPhone15Pro都有。

接口方面

给了耳机口+2个雷电4+MagSafe，其中Magsafe和雷电口都可以充电，其中雷电口是可以在视频+数据+供电同时进行的，因此建议买USB-C一线通的显示器（带USB-C反向供电和USB HUB功能）从而解决供电+键鼠的问题。我用的是KTC H27P3，自带2个USB+65W反向供电，5K60Hz，完全够用（缺点可能是5K模式下，USB只能运行在USB2.0，如果要运行在USB3.0那只能是4K60）
但是这个情况下，1个雷电接显示器，就只剩下1个USB-C口了，外接时就可能有点尴尬。如果是MacbookPro/Macmini机型则这方面好很多，他们本身就提供了更多接口。

文件系统方面

和Windows有较大区别，和Linux更相近，如果有Linux经验的话会好上手很多，但是传统的访达并不是那么好用，我尝试了2个第三方方案，一个是Double Commander，这玩意类似安卓的MT管理器，左右式的文件管理器，一个是VSCode。后者立大功，确实能提供和Windows平台基本一致的表现，如果你经常使用VSCode的文件管理，那么Mac的文件管理器的不同就影响不大

处理器方面

除了丐版阉割了2个GPU核心，其他都是10核心CPU+10核心GPU，不过实战下来发现日常的CPU占用都在5-20%之间，30%都很难达到，GPU基本都在睡觉，用上的时候也基本不超过30%，因此这方面多核是过剩的，结合优势的单核性能确实体验不错。

游戏方面

不出意料的失望，我测试了2款游戏，幻塔和鸣潮，其中幻塔是较小的安装包+安装后下载主要内容，和其他平台逻辑差不多，鸣潮则是直接下载一个很大的压缩包。但是这两个游戏在MAC上我稍微试了下发热爆炸键盘烫手掉帧，基本没法玩。然后试了下IOS兼容性的云版，发现键鼠操控的兼容性不佳，也基本属于没法玩的水平。因此评估，游戏还是算了吧，没主动散热的桌面级游戏没法玩，云游兼容性也不佳，因为没做原生云游，但是浏览器版的话也许是可以的，但是鼠标又是个问题。

远程方面

目前被控端我还没有找到好的方案，除了VIVO的自带远控外。我常用的无界趣连和网易UU远程都不支持MAC被控。
目前主控端的话我试了几个方案，其中无界趣连没法用；RD Client（现在叫做Windows）体验一般，不如iOS和安卓上的体验；网易UU远程效果我试了下挺不错，能DIY的参数也挺多。

生态方面

生态方面一直上苹果的优势点，抛开被我淘汰的iPad（能当拓展屏啥的），抛开基本的应用接力，这些特点用法值得一提。
iPhone+Mac，首先Mac可以直接镜像iPhone，而且似乎并不要求使用同一个Wi-Fi，但是体验一般，iPhone亮屏的情况不能用。其次就说通知和小组件共享，可以把小组件直接放在Mac上，但是通知虽然同步过来了，但是点击还是会自动打开iPhone镜像去操作，Mac原生的小组件似乎没几个。Mac运行iOSApp也是比较有限的，大部分的确实也不能用。同时iPhone的摄像头和麦克风可以同步给Mac无线使用。但是大部分都是Mac利用了iPhone，在iPhone上感知不到Mac的好处。在Mac的电池面板中也看不到iPhone，iPhone也看不到Mac。
AirPods+Mac，首先在先进产品中，现在能智能和手动的切换调度AirPods播放谁，但是不能都播放，不过电量可以同时在iPhone和Mac上看到。切换还是挺方便的，调度上也还行。包括降噪在内的高级功能俩边都是支持操作的。
Apple Watch+Mac，Watch能一定程度上替代部分的Touch ID使用，比如解锁屏幕，商店授权等，不过也有时候调不出来，但是能用上的概率比iPhone的使用Watch解锁频率要高多了。其他方面倒是不明显，Mac还是不能看见Watch电量，不知道为什么不打通这一点。
对于前台调度这个功能，和iPad那个一样，但是我感觉并不是很好用，最后用了一阵子还是回归传统。

外观方面

整体上属于银不银蓝不蓝的中间态，很受环境光线影响。整体外观设计确实没问题，符合苹果的一贯风格，但是要注意建议不要使用屏幕膜和键盘膜和防尘布挡键盘，因为发现确实很影响合盖，机器预留的缝隙确实不足，放这么多东西真不小。整体重量我觉得还行，相当于2个平板。刘海并不是很影响体验，尤其是大部分场景使用外接显示器的情况，如果大黑边和刘海选一个我还是选刘海，但是这个刘海没有做成灵动岛，不知道为什么，感觉特别突兀，没有什么软件上的优化。
由于没有风扇，能得到和手机平板一致的无声体验，当然前提是没有外接带风扇的拓展坞和硬盘盒。
然后CTRL/WIN/大小写等键和鼠标滚动都不同，需要时间适应，虽然大部分可以在设置修改。

软件方面

整体上来说，使用飞书的体验完全没区别，现在的QQ/微信/QQ音乐/VSCode/Chrome等软件体验基本是一致的。基本日常和办公应该是没什么问题的。Office/WPS可能功能略有阉割但是影响不大。能额外运行某些iOS软件确实有意思，尤其是某些付费软件。
对于网盘来说，iCloud肯定说深度集成的，Onedrive我试了下体验和iCloud差不多，但是Pcloud我试了下体验确实不太好（包括代理和频繁跳登陆等），然后我还试了下百度网盘，感觉太费内存，要用1G+，大部分情况下更愿意浏览器打开，其他网盘没有测试。
对于罗技设备来说，发现不支持老的罗技LGS驱动，被迫使用新的GHUB驱动了。
对于自带输入法来说，不知道为什么感觉很弱智，也许是因为刚刚用，没记忆习惯，对比iOS/安卓/Win自带的感觉经常没成功得到我要输入的词汇。
对于压缩软件，发现没有提供7Z的GUI，最后用了Keka这个软件。
对于抓包软件，Reqable也支持Mac，没有问题。
对于SQL软件，DBeaver也支持Mac，没有问题。同时我还发现SQLynx和Beekeeper Studio也还可以。
对于终端，怎么用我都感觉不如Windows11自带的PowerShell好用，最后我使用了iTerm
对于VSCode，要注意配置同步时会把代理配置也同步过来，一开始我就因为这个导致一登陆同步，VSCode就断网。其他体验我感觉基本一致，这种基于浏览器内核的软件（Electron with Chromium）在跨平台上体验都比较一致。

网络方面

我试了下还是不支持Wi-Fi6-160Mhz，没成功连上，感觉网上那些还是在吹牛，没法复现，因此Wi-Fi下达不到千兆网速，苹果这方面一直做的不太行。

仅适配火箭模块，其他平台未测试

和PC-WEB不同的是哔哩哔哩标准客户端会大量使用基于IPv4+端口的PCDN/MCDN（以下简称PCDN）
而在网页版更喜欢使用  xy218x7x125x25xy2408y8738y4000y11y0y1y0y6xy.mcdn.bilivideo.cn:4483 这种的基于XY的V4+V6域名（早期只兼容ipv4，不兼容ipv6，如果使用ipv6请求会出现回落到非pcdn的问题，最近是修复了这个问题，同时兼容了）
而且在移动端似乎更喜欢使用HTTP协议，而在PC-WEB端估计是因为浏览器管控问题而使用HTTPS协议

以前发过一个 https://www.blueskyxn.com/202408/7078.html 但是效果后来发现并不好，主要是规则和语法问题，所以今天发布一个改进版本，目前初步测试在iOS平台测试播放影视飓风的视频未发现pcdn记录，可试试看

#!name=B站去P2P CDN
#!desc=屏蔽B站P2P CDN by BlueSkyXN

[MITM]
hostname = %APPEND% *.mcdn.bilivideo.cn, *.mcdn.bilivideo.cn:*, *.szbdyd.com, *.szbdyd.com:*

[URL Rewrite]
# 替换mcdn域名为固定CDN (使用upos-sz-mirrorcos代替P2P链接)
# 正则表达式中的(\:[0-9]+)?可以匹配任意端口，包括4480、4483、8000等
^https?:\/\/([a-zA-Z0-9-]+)\.mcdn\.bilivideo\.cn(\:[0-9]+)?\/(.+) https://upos-sz-mirrorcos.bilivideo.com/$3 302

# 替换szbdyd域名 (第二种P2P方式)
^https?:\/\/([a-zA-Z0-9.-]+)\.szbdyd\.com(\:[0-9]+)?\/(.+) https://upos-sz-mirrorcos.bilivideo.com/$3 302

# 替换直接IP:端口方式 (视频服务器) - 支持任意端口
^https?:\/\/\d+\.\d+\.\d+\.\d+:\d+\/v1\/resource\/(.+) https://upos-sz-mirrorcos.bilivideo.com/v1/resource/$1 302
^https?:\/\/\d+\.\d+\.\d+\.\d+:\d+\/upgcxcode\/(.+) https://upos-sz-mirrorcos.bilivideo.com/upgcxcode/$1 302

# 其他可能的P2P组合域名
^https?:\/\/([a-zA-Z0-9.-]+)\.mcdn\.bilivideo\.cn\.szbdyd\.com(\:[0-9]+)?\/(.+) https://upos-sz-mirrorcos.bilivideo.com/$3 302

[Rule]
# 屏蔽P2P控制器域名
DOMAIN-KEYWORD,pcdn.biliapi.net,REJECT
DOMAIN-KEYWORD,hw-sh-pcdn,REJECT
DOMAIN-KEYWORD,ali-bj-pcdn,REJECT

# 允许直连CDN域名
DOMAIN-KEYWORD,upos-sz,DIRECT
DOMAIN-KEYWORD,upos-hz,DIRECT
DOMAIN-KEYWORD,upos-cs,DIRECT

近期，关于“iPhone 17 Air可能在中国大陆市场推出纯eSIM版本”的传闻引发了广泛关注。许多人可能因此对eSIM技术寄予厚望，甚至预期它将带来运营商选择和号码管理的更大“自由度”。

一、明确概念：eSIM技术的核心

首先，我们需要准确理解eSIM是什么：

• 技术形态： eSIM（嵌入式SIM卡）是一种将SIM功能直接集成到设备硬件中的解决方案，无需使用物理SIM卡。
• 实现方式： 网络服务的配置与激活通过软件远程完成，例如扫描二维码或使用运营商官方App。
• 关键认知： eSIM改变的是SIM卡的物理形态和配置方式，并未改变其作为网络身份认证工具的核心功能、基本运作原理，也无法脱离运营商的管理和国家电信政策的监管框架——这一点在中国市场尤为重要。

二、中国eSIM现状：特殊的政策与有限的应用

与全球许多市场不同，中国对eSIM技术的引入和应用采取了特定的管理策略，表现出以下特点：

1. iPhone的特殊情况： 目前在中国大陆销售的iPhone尚不支持eSIM功能，这主要是基于政策层面的考量，而非技术限制。
2. 有限的设备支持与运营商选择：
   • iPad： 仅部分型号（如第10代蜂窝网络版）获准在中国使用eSIM，且当前仅支持中国联通一家运营商。提供的套餐也有限制（独立的iPad套餐或作为共享主卡流量的副卡套餐），且iPad eSIM仅支持数据功能，无法拨打电话。
   • Apple Watch： 理论上三大运营商均可支持，但实际开通过程中，各地区、各运营商的接入策略和用户体验存在差异，新用户开通存在不确定性。目前出现大量地区的运营商停办手表ESIM业务（尤其是一号双终端和副卡小号等业务，呈现不同地区、不同运营商差异化巨大的情况）
3. 国际漫游： 支持eSIM的境外设备可通过国际漫游或特定的旅行eSIM服务在中国使用数据网络，但仍需遵守相关规定和限制。

这些情况表明，中国对eSIM技术采取的是一种审慎且有针对性的监管策略。可以预见，即使iPhone 17 Air引入eSIM，也很可能延续类似的管控模式。

三、eSIM的实际优势：客观评估

抛开市场宣传，eSIM技术在中国环境下具备的明确优势主要体现在：

1. 优化设备内部空间： 移除物理SIM卡槽可以为设备内部腾出宝贵空间，用于容纳更大容量的电池或其他元器件，有助于实现更紧凑或功能更强的硬件设计。这是一个显著的工程优势。
2. 提升特定场景下的安全性： 由于eSIM无法被物理移除，在手机丢失的情况下，可以防止SIM卡被轻易取出盗用（尤其在用户未设置SIM卡PIN码时），弥补了一个常见的安全短板。

此外，减少塑料SIM卡的生产和废弃也具有一定的环保价值，但这并非用户体验层面的核心优势。

四、eSIM在中国：理解现实、误区与管控

eSIM技术虽有优势，但在中国的具体实践中，用户需要对其现实局限、相关误区及可预见的严格管控有清晰认识：

1. 开通激活：并非“随时随地”那么简单

   • 现实局限与管控： 尽管eSIM设计便于线上操作，但国内强监管下，开通独立的主卡eSIM很可能仍需线下办理或遵循更严苛流程，线上渠道可能仅限副卡或特定套餐。这与理想的便捷体验有差距。未来可能对主副卡采取差异化管理，并强制要求多因素乃至二次实名验证（即时证件和人脸识别、远程柜台、线下柜台等），尤其在开通语音等敏感功能时。
   • 相关误区（用户控制）： 认为eSIM完全由用户控制是错误的。配置需通过官方渠道，核心信息无法修改，运营商拥有远程管理权限。“空中写卡”是远程配置能力，非用户自主权。
   • 特殊观察： 近期流传的截图显示为iPhone开卡需提供iPad信息，虽可能是界面错误，但也暗示了当前流程的复杂性和潜在的关联限制。
   • 联想物联卡的地区限制： 在涉诈、涉外高危区，比如云南全省、新疆全省、福建广东某地等，限制物联卡入网，此举有可能同步到限制ESIM上（比如禁止云南用户开通ESIM）。

2. 运营商选择与号码使用：自由度有限

   • 现实局限与管控： 目前及未来一段时间，用户很可能仍局限于国内三大运营商，且存在地区性接入差异。同时，设备同时在线（待机）的eSIM数量通常有限（如“一实体+一eSIM”或“双eSIM”），并非可无限扩展。
   • 相关误区（自由切换 & 运营商权力削弱）： 因此，“自由切换运营商和套餐”的幻想并不现实。用户仍需遵守实名制、运营商规定、套餐合约等，eSIM未改变市场基本规则。那种认为eSIM能从根本上削弱运营商话语权，让用户像点菜一样随意切换运营商的想法，忽视了国内电信业受严格监管和运营商主导的现实。当前“携号转网”的实际操作复杂性便是一个例证——用户往往需要前往线下网点，经过多重身份验证，甚至可能面临办理名额限制或特定套餐门槛（如要求转入套餐的最低消费）等障碍，这足以说明运营商切换远非轻松之事，eSIM本身难以改变这一格局。

3. 跨境使用：预期中的“双向锁区”

   • 现实局限与管控： 最可能的核心限制是实施双向锁区策略。即国行设备可能无法添加境外运营商eSIM，境外设备也可能无法添加国内运营商eSIM，形成服务隔离。
   • 相关误区（轻松用国外卡 & 国内用境外卡联网）： 这意味着国行用户带手机出国，大概率无法直接使用当地eSIM，只能依赖国内运营商的国际漫游。在此场景下，纯eSIM的灵活性甚至不如可更换当地实体卡的传统手机。同样，对于在国内直接使用境外运营商eSIM来实现所谓“国际联网”、进行国际通信或规避本地网络策略的想法，关键在于预期的“双向锁区”策略很可能从根本上阻止国行设备添加境外eSIM，使得这种连接本身就不被允许，因此讨论其网络访问规则意义不大。

4. 设备更换：或面临“补卡式”难题

   • 现实局限与管控： 为了强绑定和防滥用，将eSIM配置迁移到新设备的过程可能受到严格管控，或需多重验证、线下办理，甚至参照实体卡“补卡”流程，增加操作门槛，削弱便利性。

5. 隐私与网络访问：更严而非更松

   • 现实局限与管控： 在实名制背景下，eSIM与设备强绑定及更严的验证，理论上更易追踪，匿名性可能更低。同时，eSIM仅负责接入认证，无法绕过网络内容访问限制，所有流量受相同监管。未来可能建立专用监管平台，实施更细致的流量监控。
   • 相关误区（更高匿名性/绕过限制）： 认为eSIM更匿名或能绕过网络限制，均是对技术和监管现实的误解。

五、结论：理性看待技术演进

总而言之，eSIM是移动通信技术演进过程中的一项重要进展，它带来了明确的工程优势和一定的用户便利，但不应被视为能够颠覆现有市场格局或监管框架的“革命性”技术。

在中国特定的市场与政策环境下，eSIM的应用必然会受到一系列具有针对性的管理措施约束，其管理严格程度甚至可能超过传统SIM卡。这并非技术本身的问题，而是技术适应特定环境的必然结果。

对消费者而言，建议：

• 理性评估： 客观认识eSIM的实际优势与局限性。
• 按需选择： 根据个人实际需求判断是否选择支持eSIM的设备。
• 遵守法规： 在使用eSIM服务时，务必遵守国家相关法律法规及运营商规定。
• 保持关注： 持续了解技术发展和政策动态，避免被不实信息误导。

技术的价值在于提升效率和改善体验，而非提供规避规则的途径。无论是iPhone 17 Air还是其他采用eSIM技术的设备，都应在理解其技术实质和应用环境的基础上进行评价。

Google Gemini API 配额

模型请求限制对比表

请求数量限制（按分钟/天）

输入令牌限制（每分钟）

特殊配额限制

脚本地址 https://github.com/BlueSkyXN/GPT-Models-Plus/blob/main/ClaudeHelper.js

✴️1、可以导出 claude ai对话的内容。

✴️2、统计当前字数 (包括粘贴、上传、article的内容，含换行符/markdown语法符号等)。

✴️3、显示对话的时间、模型信息、Token用量。

成本评估算法参考 https://www.blueskyxn.com/202502/7324.html

DeepAI 是一个代理服务器，通过整合“思考链”过程来增强大型语言模型（LLM）的交互体验。

它充当中间层，接收标准 OpenAI API 兼容请求，利用独立的“思考服务”生成推理过程，然后将增强后的请求转发到您选择的 LLM 后端。

这使得响应不仅由 LLM 生成，而且还基于预先的推理分析，从而产生更具洞察力和连贯性的回答。

• OpenAI API 兼容性:
  无缝集成为 OpenAI API 设计的应用程序。DeepAI 支持 /v1/chat/completions 和 /v1/models 端点，方便接入现有应用。

• 思考链增强:
  在将用户请求发送给最终 LLM 之前，DeepAI 会自动调用预配置的“思考服务”，生成推理过程，并将该推理链（即 reasoning_content）合成到请求中，帮助 LLM 生成更具洞察力的回答。

  • 标准模式（standard） 仅使用推理链中的 reasoning_content 字段，并允许将该内容以 SSE 流形式转发给客户端；
  • 完全模式（full） 则收集并使用 reasoning_content 与 content 两部分（但完全模式下不显示思考链给客户端）。

• 灵活的后端支持:
  通过配置多个后端 LLM 服务（“渠道”）和思考服务，可根据需求自由切换或路由请求。

• API 密钥路由:
  API 密钥前缀中的渠道 ID 用于路由，将请求交给相应的后端渠道，便于进行细粒度的服务控制。

• 流式与标准响应:
  支持聊天完成请求的流式和标准响应。流式模式下，思考服务生成的 SSE 流会原样转发（包含 reasoning_content 字段），便于客户端自行解析和展示。

• 加权随机选择:
  实现了基于比例权重的随机选择算法，从多个思考服务中以概率的方式选出一个服务。权重越高，被选中的概率越大。

• 代理支持:
  支持 HTTP 和 SOCKS5 代理，可用于连接思考服务和后端 LLM 渠道，适应各种网络环境。

• 全面日志记录与优雅关机:
  提供详细的请求日志（包含唯一请求 ID、时间戳等）以及优雅的关机处理，便于监控和调试。

项目地址

https://github.com/BlueSkyXN/DeepAI

操作教程、代码等内容均在GitHub仓库，不再复述

经查，是恰好这玩意不完全免费，然后被人多访问几下刚刚好触发收费了，这玩意目前已经下架了，前一阵子通知完全停用

Nginx反向代理GitLab资源的502问题修复记录

最近在使用Nginx反向代理GitLab上的静态资源时，遇到了间歇性的502错误。通过分析错误日志发现，这些错误主要表现为连接超时:

[error] connect() failed (110: Connection timed out) while connecting to upstream

问题分析

经过研究发现，这个问题很可能与GitLab对请求来源的检查有关。当代理服务器转发请求时，携带了过多的原始客户端信息，可能触发了GitLab的安全限制。

解决方案

解决方案主要从两个方面入手：

1. 清理和标准化请求头

移除了可能触发限制的客户端信息，并统一了请求标识：

# 移除客户端信息
proxy_set_header X-Real-IP "";
proxy_set_header X-Forwarded-For "";
proxy_set_header REMOTE-HOST "";

# 统一浏览器标识
proxy_set_header User-Agent "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36";

# 标准化Accept头
proxy_set_header Accept "image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8";
proxy_set_header Accept-Encoding "gzip, br";
proxy_set_header Accept-Language "en-US,en;q=0.9";

# 移除敏感信息
proxy_set_header Cookie "";
proxy_set_header Referer "";
proxy_set_header Origin "";

2. 添加错误重试机制

为了处理可能的临时连接问题，添加了简单的重试配置：

proxy_next_upstream error timeout http_502 http_503 http_504;
proxy_next_upstream_tries 3;
proxy_next_upstream_timeout 10s;

修改效果

实施这些修改后，502错误显著减少，服务稳定性得到明显改善。这个解决方案的核心思路是"让代理请求更像普通浏览器访问"，通过清理不必要的信息和添加重试机制来提高可靠性。

经验总结

• 在进行反向代理配置时，不是传递越多的客户端信息越好，有时候反而会引起问题
• 使用标准的浏览器请求头可以减少被识别为自动化工具的可能
• 简单的重试机制对于处理临时性连接问题很有效

最终效果

    # 防盗链配置
    valid_referers none blocked *.000714.xyz *.20000714.xyz *.baidu.com *.google.com *.githubusercontent.com *.github.com *.blueskyxn.com *.qq.com *.weixin.qq.com mp.weixin.qq.com 000714.xyz 20000714.xyz blueskyxn.xyz blueskyxn.com *.tencent.com;
    if ($invalid_referer){
        rewrite ^/ https://pic.rmb.bdstatic.com/bjh/9084d1b52d9225f9d3ee02bec47235cc.png redirect;
    }

    # SSL 配置
    proxy_ssl_name gitlab.com;
    proxy_ssl_server_name on;
    proxy_pass https://gitlab.com;
    proxy_ssl_protocols TLSv1.3 TLSv1.2;
    proxy_ssl_ciphers 'TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384';

    # 请求头控制
    proxy_set_header Host gitlab.com;
    proxy_set_header X-Real-IP "";
    proxy_set_header X-Forwarded-For "";
    proxy_set_header REMOTE-HOST "";
    
    # 浏览器标识和内容协商头
    proxy_set_header User-Agent "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36";
    proxy_set_header Accept "image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8";
    proxy_set_header Accept-Language "en-US,en;q=0.9";
    proxy_set_header Accept-Encoding "gzip, br";

    # 移除敏感头信息
    proxy_set_header Cookie "";
    proxy_set_header Referer "";
    proxy_set_header Origin "";
    
    # 连接优化
    proxy_http_version 1.1;
    proxy_set_header Connection "keep-alive";

    # 缓存配置
    add_header X-Cache $upstream_cache_status;
    proxy_ignore_headers Set-Cookie Cache-Control expires;
    proxy_cache cache_one;
    proxy_cache_key $host$uri$is_args$args;
    proxy_cache_valid 101 200 1440m;
    proxy_cache_valid 304 301 302 1m;
    proxy_cache_valid 404 10s;
    expires 4h;

    # 错误处理
    proxy_next_upstream error timeout http_502 http_503 http_504;
    proxy_next_upstream_tries 3;
    proxy_next_upstream_timeout 10s;