HTTP/3 测试 & 网络指纹实验室
两部分:① 检测「当前浏览器 + 网络」能否与本站建立 HTTP/3 (QUIC) 连接(读 PerformanceResourceTiming.nextHopProtocol,h3=HTTP/3、h2=HTTP/2、http/1.1=HTTP/1.1);② 采集本连接的服务端协议指纹(JA3/JA4、PeetPrint、Akamai HTTP/2、HTTP/3 指纹)——用于反欺诈研究:UA 声称的浏览器与真实指纹是否一致。
⏳正在测试…首次请求通常走 h2;浏览器看到服务器广播的 h3(Alt-Svc)后,后续请求才会尝试 QUIC。请稍候几秒。
结论摘要
最终协商协议—
成功用上 HTTP/3 的比例—
本页加载(导航)用的协议—
服务器广播 h3 (Alt-Svc)检测中…
首次协商 h3 用了几次请求—
平均往返(responseEnd-start)—
逐次请求明细
DNS=域名解析;连接=TCP/QUIC 建连;TLS=加密握手;TTFB=首字节;单位 ms。h3/复用连接时部分阶段可能为 0。
服务端协议指纹(反欺诈)
正在从指纹服务(:8443)采集本连接的 TLS / HTTP2 / HTTP3 指纹…
指纹连接协议—
JA3
JA3 hash
JA4
JA4_r
PeetPrint (TLS1.3)
Akamai HTTP/2 指纹
Akamai H2 hash
HTTP/3 指纹
服务器看到的 UA
UA 与指纹一致性
怎么用于反欺诈:TLS 栈(JA3/JA4/PeetPrint)与 HTTP2/3 帧顺序由客户端底层库决定,伪造成本高。把这些 hash 与已知真实浏览器指纹库(如 tls.peet.ws)比对——若 UA 自称 Chrome,但 JA4/Akamai 指纹对应的是 Python/Go/curl,即高度可疑(脚本/爬虫/伪装)。这些指纹浏览器 JS 拿不到,必须服务端读原始 TLS/QUIC 帧,本页由独立指纹服务(TrackMe)在 :8443 提供。
网络层 · TCP/IP 指纹与代理判定
正在读取本连接的 TCP/IP 指纹(需服务端从 SYN 抓取)…
代理/伪装判定
TCP 推断系统
UA 声称系统
观测 TTL → 初始 TTL(跳数)
MSS → MTU(链路)
TCP 窗口 / 窗口缩放
TCP 选项顺序
p0f 式签名
怎么用于查代理:TTL/MSS/窗口/选项顺序由终结这条 TCP 连接的那台机器的操作系统内核决定。
① MSS<1460(MTU<1500) → 链路上有隧道封装,疑似 VPN(WireGuard≈1420、OpenVPN≈1400)。
② TTL 推断的系统 ≠ UA/TLS 声称的系统(如 UA 说 Windows、TTL 却是 *nix)→ 中间隔着 Linux 代理机,疑似代理/伪装。
透明代理(住宅代理/SOCKS)不改 TLS 指纹,但这一层的 MSS/OS 线索仍可能露馅。若本卡显示"不可用",通常是连接经了 NAT/负载均衡,原始 SYN 在本机不可见。
IP 信誉 / ASN(机房 vs 住宅)
正在查询 IP 归属(离线 ASN 库)…
IP 类型判定
客户端 IP
ASN
机构 / 运营商
IP 国家 ↔ 浏览器时区
怎么用于查代理:机房/托管 ASN(阿里云/腾讯云/AWS/OVH…)几乎不会是真实终端用户 → 命中即高度疑似 VPS/代理/爬虫;住宅代理则要靠 ASN + 上面的 TCP/MSS 线索综合判断。
地理↔时区不一致(IP 在美国、浏览器时区却是 Asia/Shanghai)也是代理的常见破绽。离线 ASN 库来自 iptoasn.com,无第三方请求。
客户端设备指纹(高熵 · 设备关联)
正在采集浏览器高熵指纹…
设备指纹 deviceId
Canvas 指纹
WebGL GPU 厂商
WebGL GPU 型号
GPU → 系统提示
AudioContext 指纹
已装字体(检出/探测)
屏幕 (宽x高xavail·色深·DPR)
CPU 核 / 内存(GB)
时区 / 偏移
语言
platform / 触摸点
怎么用于查同设备/批量注册:Canvas、WebGL(GPU 型号)、AudioContext、字体列表是高熵信号,组合后常接近唯一 → 即"设备指纹",能把多个账号关联到同一台机器。
服务端 TLS 指纹熵太低(百万人同为 Chrome/Win),做不到设备级关联,必须靠这一层。
三层交叉:WebGL 的 GPU 暗示的系统、UA 声称的系统、网络层 TTL 推断的系统三者应自洽——不一致往往是 anti-detect 浏览器 / 虚拟机 / 伪装。此指纹在浏览器本地计算,仅本页展示,未上传。
综合风险分(反欺诈)
正在综合四层信号评估…
本设备历史访问次数
本设备关联过的 IP 数
本 IP 背后的设备数
近 1 小时本设备访问
综合
四层(TLS 协议指纹 / 网络 TCP-IP / IP 信誉 / 客户端设备)信号,叠加
历史关联——同设备指纹簇、同设备多 IP(代理轮换)、单位时间高频(velocity)、单 IP 多设备(设备农场)——给出
可解释风险分。
→ 打开关联层仪表盘(近 200 条访问 + 风险明细)。数据存于本机 SQLite,仅用于本实验演示。
环境信息
测试时间
浏览器 / 版本
操作系统 / 平台
网络类型(如可读)
安全上下文 (HTTPS)
协议检测 API
页面地址
User-Agent
结果怎么读 / 排查
h3 出现 = 本浏览器与本网络成功建立了 QUIC 连接,UDP 443 全程通(客户端 + 网络 + 服务器都 OK)。
h2 始终 = 用不上 HTTP/3。本页测的是「到本服务器」的 h3,失败可能出在任一环节,请按下面排查:
- ⭐ 浏览器缓存(最常见):若外部工具(如
http3check.net)显示本服务器支持 h3、但本页始终 h2 —— 是你的浏览器把这个域名的 h3 标记为"坏"了(之前失败时留下的 broken alt-svc 退避,可长达数小时)。最快解法:用无痕/隐身窗口重开本页;或清除浏览数据后重试;Chrome 也可在 chrome://net-internals/#sockets 点 "Flush socket pools"。
- 服务器端:本站是否放行了入站 UDP 443(不是只开 TCP 443)。QUIC 走 UDP,很多人只开了 TCP。
- 客户端网络:所在网络/防火墙是否屏蔽出站 UDP 443(企业网/校园网常见)。可对照打开
https://cloudflare-quic.com——若那边显示 HTTP/3 而这里不行,则问题在本服务器;若那边也用不上 h3,则是你的网络屏蔽了 QUIC。
- 浏览器:是否为较新的 Chrome/Edge/Firefox,且未禁用 HTTP/3(Chrome:
chrome://flags 的 Experimental QUIC;企业策略也可能禁用)。
- VPN / 代理:是否强制所有流量走 TCP(很多代理不转发 UDP/QUIC)。