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

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;

中兴 U30 Air 亚太版随身 WiFi 详细评测及国内蜂窝网络现况

我的实测速度（频段N41）

• iPhone 14 Pro 直插我的移动卡
  • 下行速度：可达 800Mbps
• iPhone 14 Pro 使用 MiFi 插入我的移动卡
  • 下行速度：约 660Mbps（受 Wi-Fi 5 限制，理论速率 867Mbps，实际约 650Mbps）
• iPhone 14 Pro 使用 MiFi 内置卡
  • 移动网络：下行 500Mbps，上行 60Mbps
  • 电信网络：下行 300Mbps，上行 100Mbps

限速情况

• 基于性能模式下，限速如上所述。
• 测试一天内传输 1.5TB 数据，无变化，未发现云控。
• 注意：内置捂脸卡在少数商业/企业特殊基站（供应商测试站）可能出现 5G 无法通网问题，可能与捂脸卡禁区管控相关。

测速图

核心技术和功能点

1. 双卡实现效果
   • 支持双卡（内置卡 + 拔插卡），拔插卡默认使用 CMLINK 的国际漫游卡。
   • SIM 卡切换无需重启设备，但可能会短暂断网。
   • 支持双卡动态切换模式，可能会导致断网。
2. 5/4/3G 锁定
   • 支持 5/4/3G 动态锁定，锁定模式不互通。
   • 切换模式无需重启设备。
3. 锁频段
   • 支持锁定多个频段，如锁定 N41 + N78 同时锁定移动的 N41 和电联的 N78。
   • 切换锁定频段需要重启，4G 和 5G 分开锁定。
4. 锁基站/小区
   • 仅能锁定当前同频段的小区，扫描不够积极。
   • 可一次性锁定多个小区，4G 和 5G 可分开。
   • 不同卡是否共享小区不确定。
5. 性能模式
   • 支持打开性能模式，访问 性能模式。
   • 默认隐藏，仅通过 URL 访问，一次开启永久有效。
6. 充电相关
   • 使用 CtoL 线可为 iPhone 14 Pro 充电，但功率有限。
   • 不支持拔电池直接电源启动，电池可拆卸，SIM 换卡需拔电池。
7. WiFi 选择
   • 只能选择不开、只开 2.4GHz 或只开 5GHz，建议只开 5GHz。
8. USB-C 能力
   • 支持部分拓展坞输出 RJ45 作为 WAN。
   • 仅绿联 1G 多功能 HUB 可用，其他如奥睿科 2.5G 不兼容。
   • 需购买支持 RTL 芯片的拓展坞，如联想的异能者。
9. WiFi 性能
   • WiFi 模式下下行约 660Mbps，上行约 103Mbps。
   • 可能受 Wi-Fi 5 AC 协商速率限制，USB 连接可能更快。

带宽聚合

• 设备：锐捷路由器 BE72PRO + 绿联 1G 网线多功能 HUB
• 配置：内置双 WAN 聚合（建议关闭 IPv6）
• 实测结果：
  • 上传提升明显，下载提升不明显，部分测试软件检测不到。
  • 使用电信宽带 1G 下行 55Mbps，上行 55Mbps；移动 5G 下行 500Mbps，上行 55Mbps。
  • 全球网测节点：
    • 福建联通：1177Mbps 下行，110Mbps 上行
    • 福建电信：1275Mbps 下行，62Mbps 上行
    • 福建移动：978Mbps 下行，110Mbps 上行
  • 结论：联通双聚合效果不佳，电信和移动单边不通。
  • 建议：短时间上传文件时可提升 100% 上传速度。

锁频段建议

• 移动广电：锁定 N41 频段
• 电信联通：锁定 N78 频段
• 其他频段：N28 和 N1 等频段效果不佳，N1 可测试是否有效。
• 锁 4G：建议锁定 B3，部分锁定 B1/5/8 等，需逐一测试。

锁基站/小区建议

• 测试难度：需频繁重启设备，操作繁琐。
• 适用场景：固定位置使用（如晚上接路由器），解决基站负载过高导致速度不足的问题。
• 操作建议：锁定负载较低的小区，如从商业区基站切换到邻近非商业区基站。

对比旧版 U30 Air（自带内置双卡）

1. 支持插入自有 SIM 卡
   • 不需要大流量时，可将国际卡卡槽中的卡拔出，换上自己的卡，同时保留预置的移动卡。
2. 内置国际卡支持旅游使用
   • 可在香港、新加坡等地使用，目前支持 8 个地区的流量。
3. 流量用完后不断网（仅限国际卡）
   • 流量耗尽后仍可继续上网，速度限制为 256kbps，旧版未提及此功能。
4. 内置物联卡变化
   • 之前的双网版本为移动 + 电信（少部分为移动 + 联通）。
   • 约在 2024 年 10 月，电信对物联卡增加了每月 80G 流量限制。
   • 旧版双网设备默认套餐为移动，使用电信套餐需额外支付约 100 元/年购买双网版本。
   • 亚太版仅提供移动单网。

对比 F50

1. 卡槽设计差异
   • F50 为单卡设计，此机型为双卡设计（1 个内置卡 + 1 个 DIY 卡）。
2. 物联卡供应商不同
   • F50 配备的物联卡可拔除，使用飞猫的三网物联卡，服务商与中兴无关。
3. 费用和服务劣势
   • 飞猫的物联卡在费用和服务方面不占优势，需逐级加价才能升级使用。
   • 移动网络仅在三网版本提供，单网和双网版本仅有联通和电信网络，实用性不高。
   • 飞猫卡每日流量超过 50G 后断网，而中兴官方卡无此限制。

四网现状分析

联通

• 表现：在物联卡和“双不限”业务方面表现不佳。
• 卡种：
  • 小武卡、智联星等 5G 高速卡
  • “双不限”卡包括阿里卡、畅享冰激凌卡、钉钉卡、小天神卡等

电信

• 问题：与“双不限”及星卡相关的诸多问题，星卡因结算封顶被大量异地违规使用。
• 业务：虽有“双不限”业务，但数量有限，如钉钉卡、福建电信解限速、福建通勤等。

移动

• 缺点：缺乏“神卡”，大多数卡种有流量限制，解除限速操作需人工退订，成功率低。
• 优点：部分特色卡具备大流量，如北京移动冲浪卡、中兴物联卡。

广电

• 特点：普通卡以低价大流量为主，但存在封号风险，极不推荐。

技术频段分析

• 电信与联通：
  • 基本在 N78 频段上全面共享，高速网络仅部署在 N78。
  • N1 频段仅有 40MHz，无法支撑高速单点网络。
  • 部分地区仍使用 Band 1/3/5/8 等中低速网络。
• 广电：
  • 表面与移动共享网络，实则各有打算。
  • 使用多频段，优先级不明确，频段使用较为混乱。
• 移动：
  • 与广电共享部分网络，N41 网络部署出色，部分地区部署 N79 和 5G-A 进行高速网络分流。
  • 流量成本较高，普通用户获取大流量移动卡困难。

双不限示例卡种

查看详情 https://hostloc.com/thread-841467-1-1.html

国际 SIM 流量价格

国内 SIM 流量价格

注意：不可闲置半年以上，套餐可退费，已用流量按 1 元/G 抵扣。

中兴和友商价格对比