# 简谈代理检测与风控科普 **URL:** \ **Category:** 教程\ **Tags:** 原创, 服务器\ **Created:** [2026 年1 月 21 日 16:05 UTC](https://idcflare.com/t/topic/55300 "2026-01-21T16:05:19Z")\ **Posts on this page:** 20\ **Page:** 1
作者： ![ICMPMeow](https://idcflare.com/user_avatar/idcflare.com/icmpmeow/32/1371_2.png) [@ICMPMeow](https://idcflare.com/u/ICMPMeow)\ 发布日期： [2026 年1 月 21 日 16:05 UTC](https://idcflare.com/t/topic/55300/1 "2026-01-21T16:05:20Z")
很多人接触代理、VPN、远程桌面，是出于跨境办公、出海访问、旅行上网、隐私保护、公司合规接入等正当需求。但平台风控系统（TikTok/PayPal/Facebook 等）会把“异常网络、异常设备、异常行为”当成风险信号，从而触发验证码、限流甚至冻结，这个现象在ai/金融服务上极为常见。 大部分人对于代理检测其实都是一头雾水的：我挂上梯子了网站不就能看到我的ip属于某些地区如US了，为什么还能检测到我在使用梯子，实际上这是一个相当复杂和充满技术于争议的话题，今天我就来简单讲讲我们实践中最常用的代理检测方法和防护手段，做一些代理检测的科普，本文不会着重于相关技术的分析，正如本blog的其他文章一样，本文着重于向小白科普，具体的技术文章将会放在文末的reference中。 现在，先打开我开发的一个[代理检测小玩具](https://meowvps.com/tools/detector/)来看看你的隐私保护情况，如果你想专门处理某个部分，做好防护，可以跳到相应的章节。当然了，我还是希望你可以仔细的看完这篇文章，会让你对风控有更近一步的理解。 > 受限于笔者水平，文中难免有谬误，[这篇文章](https://meowvps.com/blog/detect/)当然还会多次更新，这篇文章首发于2026/1/21，最后更新于2026/1/21 ## 前言：为什么需要了解代理检测？ 很多人之所以接触代理(其实大家更熟知的名词应该是VPN)的最初目的就是为了绕过部分网站的地理位置限制，比如说：claude/gemini会因为你是中国IP而拒绝为你提供服务，金融网站也很因为你的IP而给你风控拒绝提供服务等 插句话：代理和VPN差别其实挺大的 - VPN 通常是 **系统级隧道** （把流量封装进虚拟网卡/隧道），对应用透明 - 代理（HTTP/SOCKS）通常是 **应用层转发** （浏览器/应用显式使用） - 二者都可能改变出口 IP，但在 **DNS/WebRTC/分流/IPv6** 等细节上行为差异很大 本文着重探讨代理而非VPN，除非特别指出，否则就是指代理。 ![image](https://idcflare.com/uploads/default/original/3X/e/1/e13c717e1774985b6310e735fdfe691f5b8102a9.png) ![image](https://idcflare.com/uploads/default/original/3X/c/2/c2921f5730bf3916dd1b087cd73c028c5f14cdf6.png) 这非常麻烦，很多人为了跨境电商、数字移民、隐私保护的需求，会考虑使用代理服务，帮助自己绕过简单的地理限制，从而使用相关的服务。 但，这结束了吗？ 当然没有，使用代理服务后，很多人还是会遇到下面的问题： **ChatGPT检测到VPN** ![image](https://idcflare.com/uploads/default/original/3X/c/4/c4050448c8ec24d0937b4708e5b3a36c6db94594.png) **Netflix检测到代理** ![image](https://idcflare.com/uploads/default/original/3X/8/3/83686c70cc77a8d1a1341ef1a1d202f076d4cf6e.jpeg) 这其实是网站通过你的一些行为，检测出你正在使用代理，而不是正常用户，所以对你进行了封锁。 而我要讲的代理检测，就是站在网站方的角度，告诉你网站到底是怎么进行代理检测的，我们又该如何防护？ > 当然了，网站方的具体检测手段我们是不得而知的，因为这些都会因具体的网站而变化，网站也不会公开它们的检测策略，而且很多检测都是相互关联的，通过算法来进行推断结果的，我们只能从最常见的检测方法入手，告诉大家基本的检测原理和防护方法。 **记住** ：风控看的是 **一致性** ，不是单一指标。一个指标不匹配可能没事，但多个指标都矛盾就很危险了 ## 1.IP检测 > 最基础也是最直接的检测方式 ### 1.1 IP 黑名单/信誉库 绝大多数网站最常使用的方式，对于网站方而言也是最方便的方式，直接查看用户的IP到底是不是滥用IP/机房IP，对于绝大多数用户而言，正常情况下IP要么是家宽/商宽/移动，而不会是机房IP，同时有无滥用也是一个很直接的判定手段，所以直接选择一个优质的IP对于减少风控是个非常重要的事情。 商家常用的商业 IP 信誉数据库为[MaxMind](https://www.maxmind.com/en/home)、[IP2Location](https://www.ip2location.com/)、[ipinfo](https://ipinfo.io/)、[IPQS](https://www.ipqualityscore.com/)。 - MaxMind是老牌 IP 地理定位和欺诈检测服务商，GeoIP 数据库几乎是行业标准，大量网站默认使用 - IP2Location正如其名字所言，主要提供IP 地理定位服务，代理检测不太灵敏，常作为 MaxMind 的替代或补充 - ipinfo则是中小型项目常用的数据库，开发者友好的 IP 信息 API，提供 ASN、公司、隐私检测等数据 - IPQS专注于欺诈检测和风险评分，对代理/VPN/机器人检测特别激进，金融和电商风控首选 MaxMind 和 IPQS 是你最常遇到的"敌人"——前者几乎无处不在，后者对代理检测最严格。如果你的 IP 在这两家的数据库里被标记为"数据中心"或"高风险"，大概率会被各种网站风控。 > 对于个人用户而言，MaxMind的数据库你大概是没办法知道结果了，因为这个库付费才能用(动辄300刀以上的价格，人家根本不在乎散户，专注商业)，而IP2Location是最常用于判定是否为家宽的方法，ipinfo的参考性也不错，IPQS个人用户可以随便查，不过这个库误报率较高，过于激进，只要有一点苗头就会被标记，主打一个宁可错杀1000也不放过1个。另外须知：ISP不等于家宽，很多“看起来像ISP”的网段也可能被风控标成“商业宽带/托管/滥用高发”甚至干脆其实就是机房。 示范一下最常用的两个方法： **IP2Location检查IP地址类型** 打开[IP2Location](https://www.ip2location.com/demo)，你会看到这个页面 ![IP2](https://idcflare.com/uploads/default/original/3X/a/c/ac249904c9ebfb86aa69e8e077ead8226bc77355.png) 左侧是基础信息，右侧是代理数据，左侧关注 **Usage Type** 和 **Category** 即可，此图中就是`(DCH) Data Center/Web Hosting/Transit`和`(IAB19-11) Data Centers`，即为明确的机房；右侧的话一般无数据(因为IP2这个库确实比较迟钝，不怎么关注代理数据，如果有数据那就要警惕了，连IP2都给你标注了，这个代理真的很明显了)，大部分机房就是默认这个样子 家宽的话一般就会显示 ![image](https://idcflare.com/uploads/default/original/3X/8/3/837b7c93e713268addd1ab612edfde30df96fbdb.png) 明确的`(ISP) Fixed Line ISP`和`(IAB19-18) Internet Technology`，以及下方你也可以看到 **AS Usage Type** 为`(ISP) Fixed Line ISP`，如果你是移动5G数据这类用户还会看到 MOB等类型。 **IPQS查看滥用情况** 打开[IPQS](https://www.ipqualityscore.com/user/search)即可看到大量我们需要参考的数据 ![image](https://idcflare.com/uploads/default/original/3X/0/5/05c58b33e77f5cf4c5ae804bd3630ff3324d9e08.png) 左侧可以选择严格程度，一般这个 **Strictness Level** 就是默认即可，当然你也可以看看历史情况；右侧你可以看到很多值，这个是标准家宽的情况，如果你是机房的话，那就是这样 ![image](https://idcflare.com/uploads/default/original/3X/7/e/7e615278c31ebd81795453af2da73078b62805e7.png) 这两个方法的筛选很齐全了，一个看IP类型，一个看滥用，这两个库能过其他库不会差的，当然，这两个库表现较差不等于其他库差，这两个库算是最严格的库了，表现差不等于不可用，毕竟网站到底用没用这两个库也不一定，可能用的其他库而你在其他库表现良好。 其他诸如Scamalytics/AbuseIPDB/Shodan/IPHub/DB-IP/IPRegistry/Proxycheck.io/Spur.us/iphub.info/BigDataCloud等也是不错的专业库，不一一介绍了。 **反例** ：我为什么不用国人数据库？ 首先，国人数据库根本没有国外网站使用，它的准确度和你擦屁股的手纸没什么区别，而且，这玩意准确度更是逆天 随便找一个卖`住宅双ISP`的服务商，它的测试IP为38.34.14.1，来看看国人数据库的数据 ![image](https://idcflare.com/uploads/default/original/3X/9/c/9c98396a34823049f313e6f95f616bf0773fa39f.png) ![image](https://idcflare.com/uploads/default/original/3X/b/f/bf78f2c941dc9d1f69b7487d87eff3e5b8a9ad9e.png) ![image](https://idcflare.com/uploads/default/original/3X/8/2/820d24f2ea0dc176c068a5fa0e8f3ab4d5573760.png) **TK佬：稳了，这波稳了，便宜又干净** 查查国外库 ![image](https://idcflare.com/uploads/default/original/3X/0/7/07ff44edf2ae0bb2dd1d01495ca9069694260477.png) ![image](https://idcflare.com/uploads/default/original/3X/a/7/a7da20ac8cfffa00f94df24c8ad806ab1be8329d.png) ![image](https://idcflare.com/uploads/default/original/3X/3/5/356602123d9ca5f0daa7a9fc9c7ac3b23b7bc7f1.png) ![image](https://idcflare.com/uploads/default/original/3X/d/e/de7229900b823474eb0efe783afdeaba0d8e7a55.png) **TK：稳了，又查出一个要风控的** 更多关于这方面，你可以查看[VPS IP质量检测指南](https://meowvps.com/blog/ipcheck/)来看看更深入关于IP的事情。 ### 1.2 IP 地理位置一致性 > 你不会以为选择了一个完美的IP就好了吧？这才刚刚开始 #### 1.浏览器时区 vs IP 归属时区 **原理** ：网站可以通过浏览器端获取你的系统时区，同时，网站通过你的 IP 地址查询地理位置，得到该 IP 所属的时区，二者直接对比是否一致即可 **矛盾场景** | 你的 IP | IP 归属时区 | 你的系统时区 | 结果 | | --- | --- | --- | --- | | 美国 | America/New\_York (UTC-5) | Asia/Shanghai (UTC+8) | 矛盾，这可有13 小时时差 | | 美国 | America/Los\_Angeles (UTC-8) | Asia/Shanghai (UTC+8) | 矛盾，这可有16 小时时差 | | 日本 | Asia/Tokyo (UTC+9) | Asia/Shanghai (UTC+8) | 接近但不完全一致(有点奇怪) | **检测手段：** 你可以查看[ipleak](https://ipleak.net/)、[browserleaks](https://browserleaks.com/)或者我做的小玩具[特征检测工具](https://meowvps.com/tools/detector/)来简要查看结果 ![image](https://idcflare.com/uploads/default/original/3X/7/c/7c5952bd521fed6c58a1fca210224e03b7131c95.png) **防护手段** ： 很简单，在自己的操作系统上改成与你 IP 对应的时区或者使用浏览器更改时区插件，或者干脆使用指纹浏览器，指纹浏览器会直接设置IP对应时区，这都能很好的防护。 ![image](https://idcflare.com/uploads/default/original/3X/0/f/0f67eb5cd2188a6385541cee1c16d8cbac80c7dc.png) #### 2.浏览器语言 vs IP 所在国家 **原理** ：浏览器会向网站发送你的语言偏好，给你返回合适的语言，比如你是美国人，当然希望网站给你返回英文页面 **矛盾场景** | IP | 浏览器语言 | 结果 | | --- | --- | --- | | 美国 | zh-CN（简体中文） | 美国人却用中文这对吗？ | | 德国 | zh-CN（简体中文） | 德国人却用中文这对吗？ | | 日本 | ja-JP（日语） | ✅ | | 美国 | en-US（美式英语） | ✅ | **但要注意** ：这个检测有一定的容错空间，因为： - 国外有大量华人/留学生，用中文浏览器不奇怪 - 很多人会设置多语言 所以单独语言不匹配不一定触发风控，所以往往会作为一个 **加权信号** 。 **检测手段：** 你可以查看[browserleaks](https://browserleaks.com/)来简要查看结果 - 未伪装的 ![image](https://idcflare.com/uploads/default/original/3X/a/d/ad7b88ec9fbc533aa92713cfa39a12913acbe5a9.png) - 伪装后的 ![image](https://idcflare.com/uploads/default/original/3X/b/d/bd07bdee6d4c8681ba9b055ad684ebdf2adcc360.png) **防护方法** 浏览器修改首选语言即可，如果是指纹浏览器直接配置语言列表也很方便。 ![image](https://idcflare.com/uploads/default/original/3X/e/1/e1609b961fc4b4ce8b56a1ccc52f0389334c9324.png) #### 3.系统区域设置的矛盾 **原理：除了时区和语言，还有一些更隐蔽的系统级信息可以被 JavaScript 读取，例如日期格式习惯** (“zh-CN”)、 **数字格式** (千分位、小数点)、 **货币格式偏好** (US$/￥)、 **键盘布局** (中国用户通常是 QWERTY + 中文输入法)、 **系统字体** (中文系统有宋体、微软雅黑；美国系统没有)、 **默认搜索引擎** (中国用户可能用百度、夸克)、 **剪贴板内容语言** (粘贴的是中文还是英文)等等诸如此类。 **矛盾场景** 你挂了美国代理，但是： - 系统字体列表里有"微软雅黑"“宋体” - 日期格式是 “2025年1月20日” 而不是 “1/20/2025” - 键盘布局检测到中文输入法 这些细节组合起来，就很容易暴露你是中国用户。 \*\*防护方法：\*\*这类检测非常隐蔽，几乎不可能躲过，除非你愿意真的使用英文版操作系统，用便利去换隐蔽，如果不是的话，一定会有暴露的痕迹的，符合你个人需求方便便利的一定会暴露你的地区信息，这个很难躲过的。 > 安全还是便利？这是个问题 ## 2.WebRTC 泄露 > 代理用户最常踩的坑 WebRTC 泄露是代理用户最容易忽视、也是最致命的隐私漏洞之一。很多人一键配置了代理，IP 检测网站显示一切正常，却不知道自己的真实 IP 早已通过 WebRTC 暴露给了网站。 ### 2.1 什么是 WebRTC **WebRTC(Web Real-Time Communication)** 是一套浏览器内置的实时通信技术，让网页可以直接进行音视频通话、屏幕共享、文件传输，而不需要安装任何插件。日常使用的很多服务都依赖它：Google Meet、Zoom 网页版、Discord 语音、微信网页版视频通话等等。 **为什么它会暴露真实 IP？** WebRTC 的设计目标是建立 **点对点（P2P）连接** 。为了让两个用户能直接通信（而不是所有数据都经过服务器中转），浏览器需要知道"我在网络中的真实位置"——也就是你的 IP 地址。 关键问题在于： **WebRTC 获取 IP 的过程发生在操作系统的网络层，而不是浏览器的代理层** 。 **正常用户访问网站** ![image](https://idcflare.com/uploads/default/original/3X/c/0/c04a2aeeab6fc951327d0a32755a65bcfe76cf3c.png) **代理用户配置不当时访问网页** ![image](https://idcflare.com/uploads/default/original/3X/0/a/0a996a930a3c2c895abd5dd54885b4a03294d03a.png) ![image](https://idcflare.com/uploads/default/original/3X/6/4/64622928cbf4fa2f3b51147d0a0a5b0c10264233.png) 红色路径是WebRTC启动时的流量路径，蓝色是普通网页应用的流量路径(上图)。当你代理配置不当时，就会出现这种红色路径情况，这种红色路径向STUN发起请求时(下图)，压根没经过你的代理。 WebRTC 的 ICE 收集会通过浏览器发起 STUN 交互（UDP 为主），而**很多代理配置只代理 HTTP(S)** 或只覆盖部分出站路径，导致 STUN UDP 直连。 此时网页实际上获取了你的真实IP，而且这个步骤并不复杂(只需要几行代码就可以启动这个检测)，大量网站都开启了这个检测，实际上，你的真实IP一览无余。 ![image](https://idcflare.com/uploads/default/original/3X/2/e/2eb30b3717502b48718b41d0b1e22c316be32b9f.png) ### 2.2 STUN 服务器与 ICE Candidate #### STUN 服务器是什么 STUN(Session Traversal Utilities for NAT)服务器的作用很简单： **看看我的IP是啥？** 。 大多数用户都在 NAT（网络地址转换）后面，比如家里的路由器。你的电脑可能是 `192.168.1.100`（内网 IP），但外界看到的是路由器的公网 IP。STUN 服务器就是帮你发现这个公网 IP 的。 常见的公共 STUN 服务器： - `stun.l.google.com:19302`（Google） - `stun.cloudflare.com:3478`（Cloudflare） - `stun.services.mozilla.com:3478`（Mozilla） 如上图，浏览器可以向公共STUN服务器发起请求，询问STUN服务：我的ip是啥？STUN服务器就会返回它所能看到的IP地址。 #### ICE Candidate 收集过程 当网页使用 WebRTC 时，浏览器会收集所有可能的连接方式，这些叫做 **ICE Candidate** (候选地址)。 收集过程大致如下： - 收集本地地址：192.168.1.100(内网 IP) - 向 STUN 服务器查询 - 如果则询问有TURN 服务器 问题就出在第二步上：浏览器向 STUN 服务器发送 UDP 请求时，这个请求不走浏览器的 HTTP 代理设置，而是 **直接通过系统socket 在传输层发起** 发出，这个时候就会暴露你的真实IP。 ### 2.3 防护建议 上面的流量图其实已经可以看出来怎么防止WebRTC检测了 #### 1.利用插件要求WebRTC强制走代理流量 ![image](https://idcflare.com/uploads/default/original/3X/b/8/b8665d07ea5c6272785bdacb8c60a541640ebf77.png) 下载google扩展 `WebRTC Leak Prevent`，选择`Disable non-proxied UDP (force proxy)`即可，这会强制所有 WebRTC 流量通过代理，可以防止真实 IP 泄露。 ![image](https://idcflare.com/uploads/default/original/3X/3/8/389c7dcdbfe397f559ebba8f46058aeec76eb175.png) 然后，这么做是有代价的： - 可能导致各种需要webRTC的应用异常或性能下降，如各种视频通话/Google Meet/Zoom/Discord等 - 部分在线游戏和云游戏卡顿异常 - 文件传输服务卡顿异常 **开启后效果** ![image](https://idcflare.com/uploads/default/original/3X/1/5/15317302e6b181850ff5660bd998c51780a14799.png) 哎，不是说WebRTC被设置成了走代理吗？是因为我的分流没设置好吗？我就开个全局吧 ![image](https://idcflare.com/uploads/default/original/3X/1/9/1945d3c95a95fe14a4705c0778ab85ad765364b7.png) 为什么启用插件后 WebRTC 检测不到任何 IP？ 上面我们提到了，你的电脑向STUN服务器询问IP时是调用网络层来发起请求的，但是代理软件工作在应用层，无论你怎么设置分流，都无法控制网络层的事情，电脑此时直接调用网络层来发起请求，而上面我们设置 `Disable non-proxied UDP` 后，这个选项本质上是： **宁可让 WebRTC 不工作，也不要让它用直连 UDP 把真实地址暴露出去** 。所以检测页会出现“拿不到任何 WebRTC IP”。这个时候实时视频等功能完全无法使用，这个方法最绝对，可以绝对防止WebRTC泄露，代价是部分应用无法使用。 #### 2.系统代理全部UDP/TCP流量 ![image](https://idcflare.com/uploads/default/original/3X/f/7/f76726e5e821abf53034574a852230088f657e24.png) 这个方案就简单了，而且也是最常用的方式：不单独处理webrtc的问题，直接让整个电脑所有流量都走代理，也就是我们的 **TUN模式** 。 什么是 TUN 模式？ TUN 是一种虚拟网络设备，工作在网络层(Layer 3)，当你的代理软件开启 TUN 模式时，它会： - 创建一个虚拟网卡（比如 `utun0` 或 `tun0`） - 接管系统的所有网络流量(包括 TCP 和 UDP) - 在操作系统网络栈层面就把流量导向代理 - 系统级代理，所有软件自动走代理(再按分流规则分流) 注意，这需要： - 管理员/root 权限(所以系统可能会问你是否以管理员权限运行这个程序) - 可能与某些 VPN 冲突 - 部分杀毒软件会拦截虚拟网卡创建 一句话：TUN 更像是“系统级接管”，它通过虚拟网卡把系统的出站流量（包括 TCP/UDP）统一纳入同一套转发/规则体系。这样 WebRTC 的 UDP 出站就不容易绕过代理路径，从而降低泄露概率。 > 这个也可以防止DNS泄露，不过这是后话了 **开启后效果** ![image](https://idcflare.com/uploads/default/original/3X/2/c/2ca3e8c09922018b5244dffd9e783948498fc6a6.png) IPV4的WebRTC泄露就彻底解决了，但你会发现：我的IPV6怎么还在泄露？ 这个其实是因为很多代理软件默认只处理 IPv4，根本就不会去动IPV6的路由表，而且很多代理不支持 IPv6，更关键的是：大多数时候系统压根就不用stun，因为IPV6直接就写在设备网卡上了，无需询问stun"我的IP是多少"而是直接一看网卡，就知道IPV6是啥，直接就发送了，不需要向任何外部服务器查询，自然也无所谓什么代理。 想要防护很简单，只要开启这个设置使用默认网络接口，这个选项主要是在浏览器层面减少/限制 WebRTC 暴露的候选地址来源（例如不暴露非默认接口、减少本地地址候选），从而降低泄露概率。 ![image](https://idcflare.com/uploads/default/original/3X/f/2/f2dc0b1d31846ac50a7dacb1660129aec76ede55.png) ![image](https://idcflare.com/uploads/default/original/3X/a/0/a0b911ab2425e1028aefe50bdbf7f92b0e7232b1.png) 这个方案同样会降低性能，无可避免的影响体验。 有没有既要隐私又要性能的方案：没有的，兄弟，没有的，因为你要知道，网站想要和你建立最佳的沟通，只能通过UDP二者直连，任何其他方案都会增加延时，而二者直连的，网站是一定要知道你的IP的，这二者根本无法调和。 隐私和实时性通常要做取舍：P2P/直连 UDP 延迟最低，但最容易暴露网络信息；走中继/隧道更隐私，但延迟和稳定性可能变差。最佳实践往往是“按用途分开”：需要实时通话的场景放宽限制，日常浏览则优先隐私。 ## 3.DNS 泄露 > 隐蔽但致命的指纹 DNS 泄露是一个经常被忽视、但非常致命的隐私漏洞。很多人以为配置好代理、IP 检测通过就万事大吉了，却不知道自己的 DNS 查询请求正在"告密"——直接暴露你的真实位置、ISP 信息，甚至浏览记录。 > 这个其实不是用来防网站方的，一般网站方没这么闲的蛋疼，一般是为了防止国内DNS知道你在浏览什么网站用的 ### 3.1 什么是 DNS 泄露 DNS(Domain Name System，域名系统)就像互联网的"电话簿"。当你在浏览器输入 `114514.homo` 时，电脑需要把这个域名翻译成 IP 地址（比如 `114.51.4.191`）才能真正访问网站。这个翻译过程就是 **DNS 查询** 。 什么是 DNS 泄露？ **DNS 泄露** 指的是：你明明挂着代理，浏览器流量走的是代理 IP，但 DNS 查询请求却 **绕过代理** ，直接发送到你的本地 ISP 的 DNS 服务器。 **无代理正常访问流程** ![image](https://idcflare.com/uploads/default/original/3X/4/e/4eb0372ca7d9f097710b2bf0f4991fb8e4415677.png) 用户的DNS请求发送到ISP的DNS服务器(比如中国电信的DNS)，DNS服务器返回域名对应的IP地址，用户通过这个IP访问网站。这很正常，因为你本来就是中国电信的用户。 **使用代理但DNS没有泄露的情况** ![image](https://idcflare.com/uploads/default/original/3X/6/9/69a81b8a5cd5cf9fb93cdcb8ab2396925e1a87a9.png) **使用代理但DNS泄露的情况** ![image](https://idcflare.com/uploads/default/original/3X/0/c/0c0eb859849f913c297dd8891dfb3febaf0ac264.png) 看起来你在使用美国的代理，网站看到的IP是美国的，但是： - 你的DNS请求仍然发送到中国电信的DNS服务器 - 网站可以通过特殊手段检测到你的DNS服务器IP - DNS服务器的归属地是中国，但你的出口IP是美国 **矛盾了！** 网站会想：你明明是美国IP，为什么DNS查询来自中国电信？一眼丁真鉴定为代理。 ### 3.2 检测原理 打开[ipleak](https://ipleak.net/)来确认自己是否出现DNS泄露，只要出现DNS服务器中出现任何一个中国大陆地区的，那就是发生了DNS泄露。 DNS泄露检测的核心原理是：让你的浏览器查询一个特殊的域名，然后看看是哪个DNS服务器来查询的。 **EDNS Client Subnet (ECS)** 检测通常基于权威 DNS 看到的递归解析器来源；ECS 在部分情况下会进一步暴露客户端子网信息。这是DNS协议的一个扩展，原本是为了优化CDN性能而设计的，但也可以被用来检测DNS泄露。 **工作流程：** 1. 网站生成一个唯一的随机子域名，比如：`dnstest1234567890.edns.ip-api.com` 2. 你的浏览器尝试访问这个域名 3. 你的DNS服务器向 `ip-api.com` 的权威DNS服务器查询这个域名 4. 权威DNS服务器记录下： **谁来查询的** （你的DNS服务器IP） 5. 网站通过API获取这个DNS服务器的IP和地理位置信息 \*\*关键点：\*\*浏览器查询的域名是随机生成的，所以不可能被缓存，必然会触发真实的DNS查询。 ![image](https://idcflare.com/uploads/default/original/3X/4/c/4cc154214d413f9d3f45112cf6b500a0f224c560.png) ![image](https://idcflare.com/uploads/default/original/3X/5/4/54732deb3a2b88d23f5b0f312edc4faca2cd448f.png) ### 3.3 什么原因会出现DNS泄露？ **代理软件配置不当** ： 大部分HTTP/SOCKS代理默认 **只代理应用层流量** ，不代理DNS查询。DNS查询发生在更底层，所以会直接从你的本地网络发出。 ```auto HTTP请求 → 走代理 DNS查询 → 不走代理，直接用系统DNS //DNS泄露 ``` **操作系统DNS缓存** : Windows/macOS/Linux都有DNS缓存机制。即使你配置了代理，操作系统可能仍然使用之前缓存的本地ISP DNS服务器。 **IPv6 DNS泄露** ： 很多代理只处理IPv4流量，但如果你的网络支持IPv6，DNS查询可能通过IPv6直接泄露。 ### 3.4 防护手段 V2RAYN：无需进行任何防护，V2RAYN会自动配置，大部分情况下不会出现DNS泄露的情况，但默认配置不一定能完全防止泄露 Clash系列：选择合适的分流规则和DNS覆写规则。 更具体的你可以看这个[DNS泄露篇](https://youtu.be/fqREM6b25SY) 当然我也知道有些人比较暴力，直接进行TUN+全局代理的方式来进行DNS泄露防护，这有点暴力但确实有效，只要你能接受全机流量代理引起的各种小麻烦(国内网站卡顿，微信登录IP变成国外等)… ## 4. TCP/IP 协议栈指纹 > 操作系统级别的"身份证" ### 4.1 什么是 TCP/IP 指纹 TCP/IP 指纹是一种通过分析网络数据包中的协议栈特征来识别操作系统的技术。就像每个人的指纹都是独一无二的，不同操作系统在实现 TCP/IP 协议时，会在数据包头部字段中留下独特的"指纹"。 ![image](https://idcflare.com/uploads/default/original/3X/f/a/fa38e797488c33e79cba6ddb7ce67cd69191feae.png) ![image](https://idcflare.com/uploads/default/original/3X/1/c/1c2bcbc77843e9e784040879b64b56cc239b0527.png) > **不一致 ≠ 必然代理** ，只是一个风险信号(中间设备/指纹库误判也可能导致不一致) > > 注：ChromeOS/Android 与 Linux 内核特征高度相似，推断可能存在混淆 **核心原理：** 每个操作系统在处理 TCP/IP 连接时，会在数据包头部设置不同的默认值，包括但不限于： - **TTL（生存时间）** ：Windows 通常为 128，Linux 为 64，macOS 为 64 - **窗口大小（Window Size）** ：不同 OS 的初始 TCP 窗口大小各异 - **TCP 选项字段** ：如 MSS、SACK、时间戳等的排列顺序和值 - **DF 标志位** ：Don’t Fragment 标志的设置策略 - **IP 头部的 ID 字段** ：递增方式不同 这些细微差异在正常网络通信中不影响功能，但可以作为识别操作系统的依据。 当你使用代理时，浏览器声称的操作系统（通过 User-Agent）可能是 Windows 10，但实际发出 TCP 数据包的却是代理服务器的 Linux 系统。这种不一致性会暴露代理的存在。 ### 4.2 检测逻辑 网站方会获取两个信息 **信息1：UA 声称(可控)** 浏览器中的UA 声称信息，这个可以由用户设置，比如指纹浏览器中就可以设置 ![image](https://idcflare.com/uploads/default/original/3X/4/e/4e0a39504c9a64ebacf4c69a89f73ed2f3580380.png) 比如如果我设置为Mac OS，进入检测页面就会是这样 ```auto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 Chrome/120.0.0.0 Safari/537.36 ``` ![image](https://idcflare.com/uploads/default/original/3X/f/f/ffcb141c719480376ae475e2957fe6dbeb065af1.png) UA声称是你的浏览器告诉网站方的，你可以随意修改，想要什么就是什么。 **信息2：指纹推断(难以伪装)** 这是通过分析 TCP 数据包推断出的系统， **只和你的出口节点机器有关** 。 - **内核级别** 的泄露 - 与用户客户端配置 **无关** - 理论上可以调节出口机器的系统指纹，但需要： - 修改内核参数（需要 root 权限） - 专业的网络知识 - 操作不当可能影响网络连接 当网站方获取了你的这两个信息后，简单对比即可，如果你没有使用代理，那么二者推断应当是一致的。 ### 4.3 防护建议 无需防护，不是因为OS指纹识别不准，而是因为防护代价太高了，完全不在日常使用的防护手段内。即使p0f、Nmap 等工具的 OS 指纹识别准确率相当高，但在网页风控场景中确实较少直接使用（因为需要原始数据包访问权限）。 > 其实你用指纹浏览器调一下系统使之与出口机器系统一致即可(什么新时代掩耳盗铃 这个检测作为一个技术扩展了解即可，实际威胁很小，重点关注 **WebRTC 泄露** 和 **时区匹配** 这些更实际的问题。 ## 5.RTT 延迟分析 > 通过时间差推断代理存在，这是一种“理论上可行、实现成本不高，但噪声较大、现实中不算主流”的思路，更多作为技术扩展理解。 RTT（Round-Trip Time，往返时间）延迟分析是一种相对隐蔽但非常有效的代理检测方法。这个方法的核心思想是： **如果你使用代理，数据包要多绕一圈，必然会增加延迟** 。 ### 5.1 原理 > 哎呀我真不想这个章节变成枯燥硬核的计算机网络课，我会简化整个流程让人一看就懂，你真想深入理解你只需要把这个部分复制给ai，它一定可以说出根本原理 其实原理就一张图 ![image](https://idcflare.com/uploads/default/original/3X/6/b/6be43575af4060af5d86a9fdfedd2b39f64b4eb9.png) **TCP RTT(服务端视角)**：服务器（或边缘网关）测到的“对端 socket 的往返时间”，对它来说“客户端”是谁，它就测到谁。 **WS RTT(浏览器视角)**：浏览器通过 WebSocket 的 ping/pong 或短请求多次测得的往返时间，包含了浏览器到对端的真实路径以及一定的应用层开销。 这二者之间必然有差距，因为你的浏览器发起请求到代理服务器一定需要时间，这个时间差达到一定程度就可以认为是代理，因为如果你没有使用代理的话，你的测量图是这样的 ![image](https://idcflare.com/uploads/default/original/3X/4/e/4ed5022ffc180cb06cbd3713c252bb09655a7de7.png) 也许会有网络波动，但一般都在10ms以内 ### 5.2 为什么有效 ![image](https://idcflare.com/uploads/default/original/3X/4/d/4d9d89a0f1448874ec2a29189ed906bfc78b38c5.png) 首先，TCP这一段你没有任何可能可以更改，因为这个是网站方直接测量你的出口节点到网站的延时，和你怎么客户端怎么设置毫无关系；wss握手这一段，或许你可以修改客户端 JavaScript，使得它和TCP这一段相同，但问题是：你怎么知道TCP这一段是多少？网站方不告诉你TCP延时时，你怎么去伪造呢？ > 简单而有效的检测方法，一击毙命 > > “Because this detour over the proxy server often incurs a geographical and application level delay, we are able to observe a difference in latencies! … A proxy server such as 3proxy however usually runs on a off the shelf Linux server and the IP packet has to be passed through the Linux TCP/IP stack all the way up to the user land where the proxy server establishes a new TCP/IP connection with the web server. This takes some milliseconds, at least two RTT’s for a new three-way TCP/IP handshake.” ### 5.3 防护难度 非要说绕过其实是有办法的：你将wss-tcp的延时缩小到10ms内(大致)就可以了，这样就会在误差范围内，让网站方无从知道你是否真的使用了代理。通俗的说就是：你离代理服务器的出口足够近，比如深圳-\>HK-\>网站，深圳-HK这一段可以缩短到5ms内，网站方从延时上看不出明显差异，比如上图，你会发现我的延时差额普遍都在30-40ms,因为我到HK服务器的延时就是35ms左右，如果我切换为日本服务器，就会变成这样，你可以看懂到日本的TCP延时变成了0ms，近乎为0. ![image](https://idcflare.com/uploads/default/original/3X/8/6/8642ea1e551254fb4a7e3b30ffd32f75d5d87bb4.png) 其他情况来看，几乎没有可能绕过。 好消息：没有听说过有网站使用这种检测方法，这个仅仅存在于理论中，被我实现了一下而已，当成一个检测技术扩展。而且真实生产中：这类测量通常发生在边缘网关/CDN/WAF或服务器的网络层日志里，应用本身未必直接拿得到。 坏消息：只要几行代码就能实现检测，非常容易实装。 ![image](https://idcflare.com/uploads/default/original/3X/4/f/4f0aa4c87a9652668ac40403971586bc7ef06ac7.png) ## 6.浏览器指纹 > 浏览器本身就像一张"身份证"，每次访问网站都在主动暴露你的特征 ### 6.1常见指纹维度 浏览器指纹是通过收集大量浏览器和设备特征，组合成一个独特的"指纹"来识别用户。即使你没有登录，网站也能通过指纹追踪你。 打开[BrowserLeaks](https://browserleaks.com/)这个最全面的指纹检测工具集，你可以看到浏览器能获取你的一切信息 - **Canvas 指纹** ：网站让浏览器在画布上画一段文字/图形，再把像素结果做成哈希值。不同系统、显卡驱动、浏览器渲染实现会产生细微差异，因此可以用来“识别同一设备环境”。它不等于“检测代理”，但如果渲染结果呈现出明显的“桌面环境特征”，而你却声称自己是 iPhone，这种不一致会成为风控加分项。 - **WebGL 指纹** ：WebGL 能暴露“图形渲染器的身份线索”，用于判断你到底像手机还是像电脑(有些浏览器/隐私设置会对这些信息做模糊处理，所以风控通常当作加权信号)。比如你在指纹浏览器中声称设备： iPhone 13Pro，结果WebGL却显示NVIDIA GeForce GTX 1060，iPhone上怎么可能有 NVIDIA 显卡，一眼丁真鉴定为假。 - **字体指纹** ：系很多时候网页并不是直接拿到“完整字体列表”，而是通过测试一些常见字体是否存在、渲染宽度差异来推断系统/地区。如果 IP 显示在 US，但环境里出现大量中文字体特征(微软雅黑/宋体)，就会显得不自洽。 - **屏幕分辨率&硬件并发数** ：网站发现你声称的iPhone 13 Pro(1170×2532&6核)实际上是1920×1080&16核，明显不自洽(分辨率可能受外接显示器/缩放影响，核心数也可能受省电/虚拟化影响，所以一般是和其他信号一起看)。 - **Audio Context 指纹** ：网页用一段“合成音频计算”生成结果，不同系统/驱动/浏览器的实现细节会让结果有细微差别，因此可用于识别环境。 - 等等… **风控系统不看单个指纹，而是看各指纹之间是否自洽。** ![image](https://idcflare.com/uploads/default/original/3X/3/6/36329cdf58c10b3c82f6274d206df92bf80e4c23.png) 你也可以看看这两个常用的网站的一致性评分[iphey](https://iphey.com/)、[pixelscan](https://pixelscan.net/fingerprint-check)。 ### 6.2 自动化/无头浏览器检测 > 很多代理用户用 Puppeteer/Selenium 批量操作账号，这类工具有明显特征 可以看看这个来看看机器人特征[sannysoft](https://bot.sannysoft.com/) 检测点 1：`navigator.webdriver` 属性 ```auto // 正常浏览器 navigator.webdriver === undefined // Selenium/Puppeteer 默认 navigator.webdriver === true //直接暴露自动化工具 ``` > 其实还有很多这样的检测，比如 > > - Headless 特征（窗口/渲染/字体/权限行为） > > - 事件行为（鼠标轨迹、滚动节奏、输入节奏） 检测点 2：扩展/插件特征异常(比如插件数量为0) 某些自动化环境的扩展列表、MIME types、语言数组等会出现“过于incognito/过干净”的特征；单独看不一定有问题，但和其他信号叠加会更可疑。 检测点 3：权限请求/权限状态异常 正常用户环境里，请求通知/摄像头等权限通常会出现浏览器提示；而某些自动化/受控环境会直接返回固定结果，或者表现出“与真实用户不一致”的权限状态。 ## 7.结语：代理检测的猫鼠游戏 写到这里，你可能会问： **有没有完美的解决方案？** 答案很简单，也很残酷： **没有** 代理检测本质上是一场不对称的战争： - 网站方有无限的服务器资源、专业的风控团队、海量的行为数据 - 你只有一台电脑和散落不成体系的各种技术文章 记住三个原则： - **风控看的是一致性，不是完美** ：你不需要伪装得天衣无缝，你只需要减少矛盾 - **了解你的威胁模型** ：跨境电商多账号(全方位隔离 + 行为模拟)、隐私保护(重点防DNS/WebRTC泄露)、只是想用ai(关注IP质量 + WebRTC + 时区) - **技术只是工具，不是目的** ：代理检测的终极目标不是"绝对隐匿"，而是在隐私、便利、成本之间找到平衡。 这是一场永无止境的战争，检测方和被检测方，也许你改变不了什么，至少，你知道，当你被风控时可能发生了什么？ **知道真相，是改变的第一步** 看了这么多的风控文章，我只想说：我管你这哪的，我一点都不想知道怎么防止代理检测，我只想最高性能最快的上网冲浪，至于风控和隐私泄露，我已经不差这点了————来自一个用尽全力伪装还是被风控的可怜猫猫 References： - [7 different ways to detect Proxies](https://incolumitas.com/2021/10/16/7-different-ways-to-detect-proxies/) - [代理检测的挑战：解决数据库老化和准确性问题](https://gosecure.ai/blog/the-challenges-of-proxy-detection-addressing-database-aging-and-accuracy-issues) - [How Unique Is Your Web Browser?](https://coveryourtracks.eff.org/static/browser-uniqueness.pdf) - [WebRTC泄露研究](https://github.com/diafygi/webrtc-ips) - [我真的很建议你看看CF的Bot检测博客](https://blog.cloudflare.com/tag/bots/) - [Transmission Control Protocol (TCP)](https://datatracker.ietf.org/doc/html/rfc9293) - [DOMAIN NAMES - CONCEPTS AND FACILITIES](https://datatracker.ietf.org/doc/html/rfc1034) ---
作者： ![block](https://idcflare.com/letter_avatar/block/32/6_22734026db12803ebb3e059622ac3534.png) [@block](https://idcflare.com/u/block)\ 发布日期： [2026 年1 月 21 日 16:16 UTC](https://idcflare.com/t/topic/55300/2 "2026-01-21T16:16:43Z")
**知道真相，是改变的第一步** 看了这么多的风控文章，我只想说：我管你这哪的，我一点都不想知道怎么防止代理检测，我只想最高性能最快的上网冲浪，至于风控和隐私泄露，我已经不差这点了————来自一个用尽全力伪装还是被风控的可怜猫猫 References： - [7 different ways to detect Proxies](https://incolumitas.com/2021/10/16/7-different-ways-to-detect-proxies/) - [代理检测的挑战：解决数据库老化和准确性问题](https://gosecure.ai/blog/the-challenges-of-proxy-detection-addressing-database-aging-and-accuracy-issues) - [How Unique Is Your Web Browser?](https://coveryourtracks.eff.org/static/browser-uniqueness.pdf) - [WebRTC泄露研究](https://github.com/diafygi/webrtc-ips) - [我真的很建议你看看CF的Bot检测博客](https://blog.cloudflare.com/tag/bots/) - [Transmission Control Protocol (TCP)](https://datatracker.ietf.org/doc/html/rfc9293) - [DOMAIN NAMES - CONCEPTS AND FACILITIES](https://datatracker.ietf.org/doc/html/rfc1034) ---
作者： ![coffox](https://idcflare.com/user_avatar/idcflare.com/coffox/32/20312_2.png) [@coffox](https://idcflare.com/u/coffox)\ 发布日期： [2026 年1 月 21 日 16:36 UTC](https://idcflare.com/t/topic/55300/3 "2026-01-21T16:36:47Z")
> [@ICMPMeow](#): > > 你只有一台电脑和散落不成体系的各种技术文章 :tieba_087: ---
作者： ![Eason\_Book](https://idcflare.com/letter_avatar/eason_book/32/6_22734026db12803ebb3e059622ac3534.png) [@Eason\_Book](https://idcflare.com/u/Eason_Book)\ 发布日期： [2026 年1 月 21 日 16:52 UTC](https://idcflare.com/t/topic/55300/4 "2026-01-21T16:52:10Z")
都是硬货👍 ---
作者： ![MrChen-hero](https://idcflare.com/user_avatar/idcflare.com/mrchen-hero/32/22434_2.png) [@MrChen-hero](https://idcflare.com/u/MrChen-hero)\ 发布日期： [2026 年1 月 21 日 17:05 UTC](https://idcflare.com/t/topic/55300/5 "2026-01-21T17:05:49Z")
感谢猫猫 👍 ---
作者： ![Catchable6](https://idcflare.com/user_avatar/idcflare.com/catchable6/32/821_2.png) [@Catchable6](https://idcflare.com/u/Catchable6)\ 发布日期： [2026 年1 月 21 日 18:49 UTC](https://idcflare.com/t/topic/55300/6 "2026-01-21T18:49:44Z")
可能还有不少人不知道Netflix的iOS app具备识别代理的能力，IP本来是可以支持解锁非自制剧，一旦打开iOS版看，不到半天即会被它封锁只能看自制剧。如果IP足够健康的话，远离iOS版，一周即可放生恢复清白，慢则可能两周至一个月。所以任何对IP敏感的平台，尽可能使用浏览器访问是一个好习惯，因为app版往往具备更多检测能力。 > [@ICMPMeow](#): > > #### 浏览器时区 vs IP 归属时区 > > **原理** ：网站可以通过浏览器端获取你的系统时区，同时，网站通过你的 IP 地址查询地理位置，得到该 IP 所属的时区，二者直接对比是否一致即可 > [@ICMPMeow](#): > > #### 2.浏览器语言 vs IP 所在国家 我日常大多数平台都是用日本IP，同时iOS的语言、地区、时区都是一致日本，已经有十多年了，可能因此避开了大部分潜在风控。 在Mac浏览器登入美国银行时，除了将规则模式改全局，也会将系统时区也一并改为美国（MacOS系统语言日常是英语、地区是美国）。 ---
作者： ![George](https://idcflare.com/user_avatar/idcflare.com/george/32/4097_2.png) [@George](https://idcflare.com/u/George)\ 发布日期： [2026 年1 月 21 日 19:02 UTC](https://idcflare.com/t/topic/55300/7 "2026-01-21T19:02:28Z")
学习，感谢佬教程~ ---
作者： ![Garfield66](https://idcflare.com/user_avatar/idcflare.com/garfield66/32/4079_2.png) [@Garfield66](https://idcflare.com/u/Garfield66)\ 发布日期： [2026 年1 月 21 日 19:33 UTC](https://idcflare.com/t/topic/55300/8 "2026-01-21T19:33:08Z")
感谢佬分享~ ---
作者： ![yqyan](https://idcflare.com/user_avatar/idcflare.com/yqyan/32/3375_2.png) [@yqyan](https://idcflare.com/u/yqyan)\ 发布日期： [2026 年1 月 21 日 21:50 UTC](https://idcflare.com/t/topic/55300/9 "2026-01-21T21:50:11Z")
学习一下，感谢分享 🙏 ---
作者： ![Luis](https://idcflare.com/user_avatar/idcflare.com/luis/32/247_2.png) [@Luis](https://idcflare.com/u/Luis)\ 发布日期： [2026 年1 月 22 日 00:20 UTC](https://idcflare.com/t/topic/55300/10 "2026-01-22T00:20:24Z")
支持支持佬！ 🥰 好吧，我放弃！ 根本过不了啦！ 🫪 ---
作者： ![163](https://idcflare.com/user_avatar/idcflare.com/163/32/58750_2.png) [@163](https://idcflare.com/u/163)\ 发布日期： [2026 年1 月 22 日 00:33 UTC](https://idcflare.com/t/topic/55300/11 "2026-01-22T00:33:34Z")
前排撸猫，太长了，慢慢看 ---
作者： ![an1xing](https://idcflare.com/user_avatar/idcflare.com/an1xing/32/10465_2.png) [@an1xing](https://idcflare.com/u/an1xing)\ 发布日期： [2026 年1 月 22 日 00:36 UTC](https://idcflare.com/t/topic/55300/12 "2026-01-22T00:36:01Z")
谢谢分享 ---
作者： ![yangshuai](https://idcflare.com/user_avatar/idcflare.com/yangshuai/32/32804_2.png) [@yangshuai](https://idcflare.com/u/yangshuai)\ 发布日期： [2026 年1 月 22 日 00:52 UTC](https://idcflare.com/t/topic/55300/13 "2026-01-22T00:52:33Z")
好文好文 ---
作者： ![ablazespark](https://idcflare.com/user_avatar/idcflare.com/ablazespark/32/12359_2.png) [@ablazespark](https://idcflare.com/u/ablazespark)\ 发布日期： [2026 年1 月 22 日 00:54 UTC](https://idcflare.com/t/topic/55300/14 "2026-01-22T00:54:19Z")
猫猫太棒了 :tieba_087: 话说这个浏览器是adspower吗，好用不 ---
作者： ![pengzhile](https://idcflare.com/user_avatar/idcflare.com/pengzhile/32/6862_2.png) [@pengzhile](https://idcflare.com/u/pengzhile)\ 发布日期： [2026 年1 月 22 日 00:59 UTC](https://idcflare.com/t/topic/55300/15 "2026-01-22T00:59:55Z")
其实最佳解决办法就是只使用远程浏览器或者远程桌面，时区语言什么的都用当地一致的。这样无论什么检测手段都无法检出。 ---
作者： ![ketto](https://idcflare.com/user_avatar/idcflare.com/ketto/32/11517_2.png) [@ketto](https://idcflare.com/u/ketto)\ 发布日期： [2026 年1 月 22 日 01:08 UTC](https://idcflare.com/t/topic/55300/16 "2026-01-22T01:08:10Z")
教程很精彩，感谢大佬的分享。 ---
作者： ![white](https://idcflare.com/user_avatar/idcflare.com/white/32/24816_2.png) [@white](https://idcflare.com/u/white)\ 发布日期： [2026 年1 月 22 日 01:44 UTC](https://idcflare.com/t/topic/55300/17 "2026-01-22T01:44:13Z")
收藏了 很赞 ---
作者： ![bai](https://idcflare.com/user_avatar/idcflare.com/bai/32/605_2.png) [@bai](https://idcflare.com/u/bai)\ 发布日期： [2026 年1 月 22 日 01:46 UTC](https://idcflare.com/t/topic/55300/18 "2026-01-22T01:46:46Z")
满满的干货 ---
作者： ![Echoliu](https://idcflare.com/user_avatar/idcflare.com/echoliu/32/715_2.png) [@Echoliu](https://idcflare.com/u/Echoliu)\ 发布日期： [2026 年1 月 22 日 01:46 UTC](https://idcflare.com/t/topic/55300/19 "2026-01-22T01:46:53Z")
点赞猫猫 ---
作者： ![GGB](https://idcflare.com/user_avatar/idcflare.com/ggb/32/10951_2.png) [@GGB](https://idcflare.com/u/GGB)\ 发布日期： [2026 年1 月 22 日 01:48 UTC](https://idcflare.com/t/topic/55300/20 "2026-01-22T01:48:33Z")
猫猫真的是输出了好多质量文章 [下一页](https://idcflare.com/t/topic/55300.md?page=2)