ICDYCT / 我能, 你也行 / I Can Do, You Can Too

前言 根据 之前的测试 ,  Caddy的HTTPS服务端的测试结果中 探针的状态与 Reality服务端的第1轮测试是一致的 思路 如果Reality"偷"证书的域名是由Caddy提供HTTP服务  VLESS-Reality-cracker 测试的结果会如何? * 测试过程的详细操作流程见  https://github.com/crazypeace/VLESS-cracker/blob/main/如果Reality"偷"证书的域名是由Caddy提供HTTP服务-操作记录.md 以下仅简略描述步骤 准备环境 1. 搭一个正常工作的 Caddy 提供HTTPS服务 略 这里以域名  drla.whatcanisay.ggff.net 为例 2. 搭建一个正常工作的 Reality 服务端, 特别地, "偷"证书的域名是由第1步中Caddy提供HTTP服务 略 这里以域名 drla.whatcanisay.ggff.net 为例 3. 在Docker中搭一个Reality 服务端, 使用宿主机的Reality服务端 同样的内核和配置 docker run -d \     --name reality-server \     --network bridge \     -v /usr/local/bin/xray:/usr/local/bin/xray:ro \     -v /usr/local/etc/xray/config.json:/usr/local/etc/xray/config.json:ro \     ghcr.io/xtls/xray-core:latest  4. 运行Reality客户端 对接Docker中的服务端 略 测试 启动POC程序 ./vless-cracker-v1 \ -i docker0 \ -f "tcp port 8443 and host 172.17.0.1 and host 172.17.0.2" \ -P characteristic.txt  \ -l info 让Reality客户端 发起Reality数据包 c...

前言 上一篇我们已经实现了 手搓复现 VLESS-Reality-cracker 那么, 按照作者的理论, 如果测试对象不是 Reality 服务端, 而是一个真实的HTTPS服务器, 探针应该显示相同的结果. 让我们试试 Caddy 提供的 HTTPS 服务 准备环境 搭一个正常工作的 Caddy 提供HTTPS服务 略 在Docker中部署一个Caddy, 使用和宿主机同样的Caddyfile和证书 docker run -d \   --name caddy-test \   --network bridge \   -v /etc/caddy/Caddyfile:/etc/caddy/Caddyfile:ro \   -v /var/lib/caddy/.local/share/caddy:/data/caddy:ro \   caddy:latest 查看Docker中Caddy的IP docker ps -q | xargs docker inspect -f '{{.Name}} -> {{range.NetworkSettings.Networks}}{{.IPAddress}}{{end}}' 访问Docker中的Caddy的HTTPS服务 curl -L --resolve 你的域名 :443: Docker中Caddy的IP   https:// 你的域名 如 curl -L --resolve drla.whatcanisay.ggff.net :443: 172.17.0.3   https:// drla.whatcanisay.ggff.net   测试1 原作者的7个探针 启动POC程序 ./vless-cracker-v1 \     -i docker0 \     -f "tcp port 443 and host 172.17.0.1 and host  172.17.0.3 " \     -P characteristic.txt \     -l info 访问HTTPS服务 curl -L --resolve drla.whatcani...

前言 前两天 在Agent和模型的帮助下, 尝试复现VLESS-Reality-cracker 担心模型糊弄我, 所以准备自己复核一遍. TL; DR https://github.com/crazypeace/VLESS-cracker/blob/main/测试操作记录.md 具体经过 我跟Agent说 总结从 git clone 项目开始 到你输出测试结果的全过程 输出一份文档 包含全部的 命令行操作 指导我完成 整个测试 这份总结里面部分东西有用, 但整体不是我当天测试的流程, 有些细节也没有总结进去. 我一边读TA的总结, 一边自己整理一份.  在这个过程中, 我发现了一些有意思的点. 1. Nodeseek上有人问我怎么看日志 我让Agent做了一个单HTML页面的分析工具. 把日志粘贴进去就能显示分析结果. 学习和分析这个项目 https://github.com/Anonymous376c1d0cf28/VLESS-cracker  对于像这样的测试日志, 制作一个单HTML页面的分析工具 https://github.com/crazypeace/VLESS-cracker/blob/main/vless-analyzer.html 2.  issues 29  提到的 30个 探针 里面有些特殊情况 探针 5：记录层长度刚好溢出 (+1 Byte) Hex: 17 03 03 40 01 00 ... (省略 16385 字节数据) 意图: TLS 标准最大长度为 16384 (0x4000)。测试边界条件，看是否能触发 record_overflow 警告。 探针 5 的数据比较大, 要单独测试.  探针 18：在 ClientHello 之前的 CCS Hex: 14 03 03 00 01 01 16 03 01 00... (ClientHello) 意图: 颠倒发包顺序。正规服务器会立刻返回 unexpected_message。 其它探针都是在重放 ClientHello 之后 发出探针的数据包. 探针 18 是在要重放 ClientHello 的时候, 在 ClientHello 之前添加一些数据, 然后发出去.  探针 30：极大的连续碎片包 Hex: 连...

前言 之前写过在PC环境下如何用浏览器检测Reality伪装效果 今天刚好需要在 Linux 环境下做同样的事情. 环境 Reality的服务端搭建在 Docker 里面, 对应的IP地址是 172.17.0.2   端口是 8443 "偷"证书的域名是  learn.microsoft.com 实践1 我一开始是参考PC上的做法, 先修改 /etc/hosts 添加 172.17.0.2   learn.microsoft.com 然后在命令行执行 curl -L https:// learn.microsoft.com : 8443 结果成功 实践2 我突发奇想, 如果我不修改hosts, 能构造一条合适的curl实现同样的效果吗? 问一下 网页版免费的ChatGPT 答案是 curl -L --resolve  learn.microsoft.com : 8443 : 172.17.0.2  https:// learn.microsoft.com : 8443 结果成功 ======== 完

装一个能操作你的VPS的agent 用你自己最熟悉的方法. 我这里以 hermes 为例, 有官方提供免费白嫖的 qwen-3.6-plus 安装教程参考 https://zelikk.blogspot.com/2026/04/hermes-agent-oracle-vps-ubuntu-root.html 登录Nous Portal提供商参考 https://zelikk.blogspot.com/2026/04/free-mimimo-v2-pro-omni-hermes-stripe.html 搭一个能运行的Reality服务端 用你自己最熟悉的方法. 我这里以 极简一键脚本 为例 curl -LO https://github.com/crazypeace/xray-vless-reality/raw/main/install.sh || wget -O ${_##*/} $_ && bash install.sh auto 8443 * 这是一整行bash命令 检查这个Reality服务端能正常工作 略 在 Docker 里面部署一个 宿主机上运行的Reality服务端的复制.  宿主机上运行的 Reality 服务端不要改动.  Docker 里面这个Reality服务端不要监听宿主机的外网, 只能在宿主机 内部使用. 跟你的agent讲上面这些话即可. 根据Docker 里的Reality服务端的配置文件, 在宿主机运行一个Reality客户端 检查这个Docker 里的Reality服务端能正常工作 跟你的agent讲上面这些话即可. 把 https://github.com/Anonymous376c1d0cf28/VLESS-cracker 拉到本地, 分析一下代码 跟你的agent讲上面这些话即可. 根据现在  宿主机运行Reality客户端 - Docker里运行Reality服务端  的这个环境, 验证这个POC 跟你的agent讲上面这些话即可. 你的agent应该给你一份 A/B 对比报告. 用这个页面的探针 进一步 测试 https://github.com/Anonymous376c1d0cf28/VLESS-cracker/issues/29 跟你的agent讲上面这些话即可....

本文是整理博客补一篇. 并没有新的一键脚本发布. 一键执行 bash <(curl -L https://github.com/crazypeace/xray-vless-reality/raw/main/install.sh) 这个一键脚本超级简单。有效语句 8 行(其中BBR 5 行, 安装Xray 1 行, 生成x25519公私钥 1 行，生成UUID 1 行)+Xray配置文件69行(其中你需要修改 4 行), 其它都是用来检验小白输入错误参数或者搭建条件不满足的。 你如果不放心开源的脚本，你可以自己执行那 8 行有效语句，再修改配置文件中的 4 行，也能达到一样的效果。 GitHub: https://github.com/crazypeace/xray-vless-reality 前提条件 一个没有被墙的VPS Reality底层是TCP直连，如果你的VPS已经被墙，那肯定用不了。出门左转  https://github.com/crazypeace/v2ray_wss 如果你能确定只是TCP有问题, 想试试UDP, 那么可以尝试 Hysteria2  https://github.com/crazypeace/hy2 具体安装过程说明 bash <(curl -L https://github.com/crazypeace/xray-vless-reality/raw/main/install.sh) 每个需要输入的地方都有提示 如果是IPv4+IPv6双栈的小鸡, 问你IPv4还是IPv6时 请按你的VPS的公网入口IP的情况填写. 公网IP为IPv4就输入 4 , 公网IP为IPv6就输入 6 . 单栈的小鸡直接按回车, 脚本会自动处理. 其它选项都可以回车使用脚本随机生成的默认值. 最后一步脚本会提示你安装WARP帮你把小鸡添加为IPv4+IPv6双栈出站的小鸡, 方便后续处理比如 Google人机验证，Youtube不让评论 等问题. 如果你不想装WARP, 此时Ctrl+C中断即可. 偷 x25519 证书 如果你不想使用脚本默认的设置, 想指定"偷"哪个域名的证书.  那么你需要确认该域名 使用了 TLS 1.3 x25519  具体操作为, 在浏览器打开你想"偷"的域名, 然后按F12 ...

Reality的原理: 当 Reality 节点收到数据包的时候, 如果 Reality 协议的验证通过, 就走节点的翻墙逻辑; 如果 Reality 协议的验证不通过, 就把数据包转发到伪装站. 后续的整个交互过程就像是在和伪装站交互一样. 我们可以简单地用浏览器验证 Reality 伪装效果. 也相当于检测 从你自己到 Reality 节点之间的数据通路是否畅通. 以这样的一个 Reality 节点为例. IP  142.171.237.9 端口  18255 伪装站 learn.microsoft.com 在电脑的hosts文件中, 设置 learn.microsoft.com 解析的IP 为  142.171.237.9   然后在浏览器中, 访问 https://learn.microsoft.com: 18255 可以看到, TLS的锁是正常的. 验证证书, 也是正常的. 从你自己到Reality节点的数据路径是畅通的之后, 如果你的节点还不能用, 那么, 就应该检查你的Reality节点验证信息了 (UUID, 公钥) ======== update 如果是用了中转后的 Reality 节点 原 Reality 节点 IP  142.171.237.9 端口  18255 伪装站 learn.microsoft.com 中转 VPS  IP 142.171.223.56 端口 28828 那么, 在电脑的hosts文件中, 设置 learn.microsoft.com 解析的IP 为  142.171.223.56 然后在浏览器中, 访问 https://learn.microsoft.com: 28828 可以看到, TLS的锁是正常的. 验证证书, 也是正常的. ======== 相关推荐 《极简一键脚本 搭Xray梯子 VLESS + Reality + xTLS 偷 x25519 证书》 《怎么把梯子分享给长辈》 《OpenClaw (Moltbot / Clawdblot) 在 VPS 上搭建 Reality 节点 过程记录》

233 boy 的 TCP 端口转发的教程 https://233boy.com/sing-box/sing-box-direct/ 下图中示意, 左边的 142.171.237.9 是被墙的VPS, 右边的 142.171.223.56 是用来做端口中转的VPS. 如果你照着教程操作一遍, 发现不能正常使用. 那么本文指导你如何排查问题所在. ======== 首先, 你要理解整个原理是什么. 左边的, 本来的reality协议节点, 底层是TCP直连, 那么是从你的 翻墙客户端(手机/电脑/...) 去连接  142.171.237.9  的 18255 端口. 现在被墙了, 那么无法直接TCP连接了. 右边的, 用于中转的VPS, 设置的 TCP端口中转 的本质是,  142.171.223.56  从端口 28828 收到的TCP数据, 会转发给  142.171.237.9  的 18255 端口.  所以, 你现在可以把本来准备发送给  142.171.237.9  的  18255  端口 的realiy数据包, 发送给  142.171.223.56  的  28828  端口; 142.171.223.56  从端口  28828  收到的TCP数据, 转发给  142.171.237.9  的  18255  端口. ======== 我们延着数据路径一段一段的排查. 1. 从我们的翻墙客户端(手机/电脑/...)连接中转VPS  142.171.223.56  的  28828  端口; a) 可以用 tcp.ping.pe 检测 142.171.223.56  的  28828  端口是否正常; b) 在你自己的电脑  tcping 检测 142.171.223.56  的  28828  端口是否可连接. 2. 在中转VPS上查 sing-box 的 access.log cat /var/log/sing...

update 2026-4-22 以前的旧套餐统统下架了 RackNerd 3T流量 20G存储 1GB内存 1核CPU 年付 $21.99   有 San Jose LADC03 https://1ladder.eu.org/rnladc03