Post #832
1.65K
Channel Public Channel
NO - Subscribers
- 4.54K
- Photos
- 1
- Videos
- 0
- Links
- 9
Recent Posts 20 shown
Post #831
1.78K
️ ◉ CF-Workers-TGProxy — 面向 Cloudflare Workers 的 Telegram Web/MTProto (KWS) 代理中继
🥇 与依赖独立 MTProxy / middle proxy 后端的传统 web-proxy不同，这份代码不再中转去一台自己的服务器，而是把客户端 MTProto 传输层在 Worker 内解出后重新封层，直接拨 Telegram 官方的 Web K 通道（kws*.web.telegram.org）。
🥈 没有 Durable Object：每条 Telegram 流拆成独立 lane WebSocket，各自背压、各自排队，整条会话不再被钉死在单线程对象上。
🥉 传输面只落一层 obfuscation（AES-CTR）重签，内层 MTProto 载荷端到端透传、Worker 不接触；上下行小包分别按 20KB / 32KB 聚合，把高频小 frame 压成更少的实际写入。
补充几点：
重点突破∶
✨ 把 Free Plan 下 Workers 的 Telegram 代理做到不断流：KWS 转换 + lanes 复用，TG下载大文件不断流、不掉速。✨
🔗 项目地址：CF-Workers-TGProxy
🥇 与依赖独立 MTProxy / middle proxy 后端的传统 web-proxy不同，这份代码不再中转去一台自己的服务器，而是把客户端 MTProto 传输层在 Worker 内解出后重新封层，直接拨 Telegram 官方的 Web K 通道（kws*.web.telegram.org）。
🥈 没有 Durable Object：每条 Telegram 流拆成独立 lane WebSocket，各自背压、各自排队，整条会话不再被钉死在单线程对象上。
🥉 传输面只落一层 obfuscation（AES-CTR）重签，内层 MTProto 载荷端到端透传、Worker 不接触；上下行小包分别按 20KB / 32KB 聚合，把高频小 frame 压成更少的实际写入。
补充几点：
- 32KB 是下行聚合上限，不是"必须攒满才发"
- 20KB 是上行合包目标，1ms 是下行观察窗
- 单会话最多 128 条 lane；单 lane 8MB / 1024 条，整会话 32MB / 16384 条
重点突破∶
✨ 把 Free Plan 下 Workers 的 Telegram 代理做到不断流：KWS 转换 + lanes 复用，TG下载大文件不断流、不掉速。✨
🔗 项目地址：CF-Workers-TGProxy
- 👍 19
- 🔥 2
Post #830
6.75K
Notif 💬 ⚡️ GrainTCP — 面向 Cloudflare Workers 的 VLESS over WebSocket TCP 主线实现 🥇 与早期那类重状态机传输代码不同，这份代码的主方向不是继续堆大缓冲 / 大定时器，而是把 Workers 下真实 TCP relay 的主热路径收紧。 🥈 上传侧使用 显式队列 + 机会性合包 + microtask drain，把高频小包尽量压成更少的实际写入次数。 🥉 下载侧已经收敛成两段式主线：大包 direct send + 立刻换新 buffer，小包…
💥💥 已更新 💥💥
- 👍 19
- 🥰 4
- ❤ 2
Post #829
10K
Notif 💬 ⚡️ GrainTCP — 面向 Cloudflare Workers 的 VLESS over WebSocket TCP 主线实现 🥇 与早期那类重状态机传输代码不同，这份代码的主方向不是继续堆大缓冲 / 大定时器，而是把 Workers 下真实 TCP relay 的主热路径收紧。 🥈 上传侧使用 显式队列 + 机会性合包 + microtask drain，把高频小包尽量压成更少的实际写入次数。 🥉 下载侧已经收敛成两段式主线：大包 direct send + 立刻换新 buffer，小包…
比较有趣的一点是 GrainTCP 用到的灰出口接口 request.fetcher.connect 早在至少2024年之前就存在了，但是通过搜索发现好像没有什么开源代码用到 request.fetcher.connect，而是导入 socket() 模块接口，所以 GrainTCP 也是第一个引入这个用法的开源项目，可以一定程度上减少1101代码特征。
- ❤ 12
- 😁 2
- ❤🔥 1
- 👍 1
Post #828
9.68K
⚡️ GrainTCP — 面向 Cloudflare Workers 的 VLESS over WebSocket TCP 主线实现
🥇 与早期那类重状态机传输代码不同，这份代码的主方向不是继续堆大缓冲 / 大定时器，而是把 Workers 下真实 TCP relay 的主热路径收紧。
🥈 上传侧使用 显式队列 + 机会性合包 + microtask drain，把高频小包尽量压成更少的实际写入次数。
🥉 下载侧已经收敛成两段式主线：大包 direct send + 立刻换新 buffer，小包 <32KB 做 grain 聚合，专门削减高频小 frame 场景下的 send() 次数与调度压力。
补充几点：
重点突破∶
✨ 将 Free Plan 计划下的 Workers 优化到极致，浏览器可下载大文件不断流不掉速。✨
整体定位：
这不是附加一堆杂项协议功能的拼装代码，而是围绕 BYOB 读取 / 上传合包 / 下载 smoothing / 并发拨号 这几条主线持续收敛出来的版本。
🔗 项目地址：GrainTCP
GitHub GitHub - ToiCF/GrainTCP: 基于 Cloudflare Workers 的 WebSocket TCP 中继，主打 BYOB 读取、上传机会性合包与下载 grain 聚合。 基于 Cloudflare Workers 的 WebSocket TCP 中继，主打 BYOB 读取、上传机会性合包与下载 grain 聚合。 - ToiCF/GrainTCP 🥇 与早期那类重状态机传输代码不同，这份代码的主方向不是继续堆大缓冲 / 大定时器，而是把 Workers 下真实 TCP relay 的主热路径收紧。
🥈 上传侧使用 显式队列 + 机会性合包 + microtask drain，把高频小包尽量压成更少的实际写入次数。
🥉 下载侧已经收敛成两段式主线：大包 direct send + 立刻换新 buffer，小包 <32KB 做 grain 聚合，专门削减高频小 frame 场景下的 send() 次数与调度压力。
补充几点：
- 32KB 是 聚合上限，不是“必须攒满才发”
- chunk=64KB 是当前通用默认档，不是源码硬上限
- concur=4 适用于 Workers / Pages 默认部署，如果改成 Snippets 形态，需手动收回到 1
重点突破∶
✨ 将 Free Plan 计划下的 Workers 优化到极致，浏览器可下载大文件不断流不掉速。✨
整体定位：
这不是附加一堆杂项协议功能的拼装代码，而是围绕 BYOB 读取 / 上传合包 / 下载 smoothing / 并发拨号 这几条主线持续收敛出来的版本。
🔗 项目地址：GrainTCP
- 👍 19
- ❤ 7
- 🎉 2
Post #827
6.69K
Shadowsocks 的实验实现 — CF-Workers-Shadowsocks
作为面向 Shadowsocks over WebSocket 场景的 Cloudflare Worker 实验项目，它不是只支持单一 AEAD 的简化代理，也不是单纯把现成流量套进 WS 转发，而是在 Worker 内直接实现：
用这种方式，把旧流密码、AEAD、Shadowsocks 2022 统一收进单文件 Worker 内完成。
CF-Workers-Shadowsocks 接近协议级实验：它不是依赖外部 SS 服务端，而是在 Workers 内直接实现Shadowsocks 的方法适配、密钥派生、分帧解包与回包加密。
📍 项目定位
① 作为研究性 / 学习性代码，验证 Workers 内实现 Shadowsocks 全方法支持的可行性。
② ✨本项目学习价值大于实际使用价值。
🔗 项目地址∶ CF-Workers-Shadowsocks
作为面向 Shadowsocks over WebSocket 场景的 Cloudflare Worker 实验项目，它不是只支持单一 AEAD 的简化代理，也不是单纯把现成流量套进 WS 转发，而是在 Worker 内直接实现：
客户端 SS 数据
→ WebSocket 接入
→ 按 method 解密
→ 解析目标地址
→ connect() TCP 出站
→ 回包再按对应 method 加密返回
用这种方式，把旧流密码、AEAD、Shadowsocks 2022 统一收进单文件 Worker 内完成。
CF-Workers-Shadowsocks 接近协议级实验：它不是依赖外部 SS 服务端，而是在 Workers 内直接实现Shadowsocks 的方法适配、密钥派生、分帧解包与回包加密。
📍 项目定位
① 作为研究性 / 学习性代码，验证 Workers 内实现 Shadowsocks 全方法支持的可行性。
② ✨本项目学习价值大于实际使用价值。
✅ 支持：旧流密码 / AEAD / Shadowsocks 2022
✅ 支持：TLS / noTLS 双场景
🔗 项目地址∶ CF-Workers-Shadowsocks
- 👍 9
- ❤ 3
- 🎉 1
Post #826
5.85K
信道已启，ToiCF 之 GitHub 道场由此铺开。
研究之种、测试之码、协议之验、工具之养，将如落叶归根，渐次归入组织之库。
库之方向，大致如下：
• 边缘网络与运行时之舞，观其行止
• 代理、隧道、中继之协议，于静室中实验
• 真实链路之验证，可复现之实测工具
• Cloudflare Workers 等平台之上，探网络之能
• 实验代码、测试数据、相关文档，皆须维护
若君对此诸方向心生涟漪，愿参与测试、整理文档、提交代码、复现实验或长期维护，便可申请加入此组织。
研究之种、测试之码、协议之验、工具之养，将如落叶归根，渐次归入组织之库。
库之方向，大致如下：
• 边缘网络与运行时之舞，观其行止
• 代理、隧道、中继之协议，于静室中实验
• 真实链路之验证，可复现之实测工具
• Cloudflare Workers 等平台之上，探网络之能
• 实验代码、测试数据、相关文档，皆须维护
若君对此诸方向心生涟漪，愿参与测试、整理文档、提交代码、复现实验或长期维护，便可申请加入此组织。
- ✍ 7
- ❤ 4
- 👍 2
Post #825
5.96K
基于 TLSClient 的进阶功能 — CF-Workers-TOR
作为面向 Tor exit 场景的 Cloudflare Worker 实验项目，它不是依赖系统 Tor 客户端，也不是简单转发现成代理流量，而是在 Workers 内通过内嵌 TLSClientMini 直接连接真实 Tor relay：
用这种方式完成 Cloudflare Workers 内部 Tor relay TLS、ntor 派生、relay cell 加解密和 exit stream 转发。
CF-Workers-TOR 接近协议级实验：它把 TLSClientMini 从"真实链路验证工具"进一步扩展成 Tor relay TLS 基座，在 Worker 内继续实现 Tor circuit 协议。
📍 项目定位
① 作为研究性 / 学习性代码，验证 Workers + TLSClientMini + Tor relay path 的可行性。
② ✨本项目学习价值大于实际使用价值。
🔗 项目地址：CF-Workers-TOR
GitHub GitHub - ToiCF/CF-Workers-TOR: CF-Workers-TOR 是一个实验性项目，在 Cloudflare Workers 中内嵌轻量 TLS 客户端，直连 Tor relay，在 TLS 层之上实现 Tor circuit… CF-Workers-TOR 是一个实验性项目，在 Cloudflare Workers 中内嵌轻量 TLS 客户端，直连 Tor relay，在 TLS 层之上实现 Tor circuit 构建、relay cell 加解密及 BEGIN/DATA 流转发，使 VLESS over WebSocket 流量可经 Tor exit 访问 clearnet 目标。 - ToiCF/CF-Wor... 作为面向 Tor exit 场景的 Cloudflare Worker 实验项目，它不是依赖系统 Tor 客户端，也不是简单转发现成代理流量，而是在 Workers 内通过内嵌 TLSClientMini 直接连接真实 Tor relay：
候选 Tor relay path
→ 第一跳 Tor relay
→ 真实 TLS 握手
→ CREATE2 / EXTEND2 建立 Tor circuit
→ BEGIN / DATA 转发普通 clearnet 目标
用这种方式完成 Cloudflare Workers 内部 Tor relay TLS、ntor 派生、relay cell 加解密和 exit stream 转发。
CF-Workers-TOR 接近协议级实验：它把 TLSClientMini 从"真实链路验证工具"进一步扩展成 Tor relay TLS 基座，在 Worker 内继续实现 Tor circuit 协议。
📍 项目定位
① 作为研究性 / 学习性代码，验证 Workers + TLSClientMini + Tor relay path 的可行性。
② ✨本项目学习价值大于实际使用价值。
✅ 支持：普通 clearnet exit proxy
❌ 不支持：纯 .onion / hidden service / onion service
🔗 项目地址：CF-Workers-TOR
- ❤ 4
Post #824
6.02K
Debug:
① TLS 1.3 解密后的明文尾部 0 padding：从末尾向前跳过 padding
② TLS 1.3 inner alert 处理：正确识别解密后的 inner alert；遇到
同步更新 HTTPSMini_v1.js 和Check_Proxy.js。
① TLS 1.3 解密后的明文尾部 0 padding：从末尾向前跳过 padding
0x00，取最后一个非零字节作为 inner content type。② TLS 1.3 inner alert 处理：正确识别解密后的 inner alert；遇到
close_notify 结束读取，其他 alert 直接抛错。同步更新 HTTPSMini_v1.js 和Check_Proxy.js。
- 👍 4
- ❤ 1
Post #823
5.64K
Notif 💬 Check_Proxy.js
修正了微小的逻辑谬误，如修补战甲的裂痕！昔日IPv4_Only那愚蠢的哨兵，竟因两路出口IP相同而陷入迷茫，致使轮询的ProxyIP域名化作“未知”迷雾，如同奥丁在迷雾中迷失方向。即刻部署此更新，荣耀归于勇者！
- ❤ 5
Post #822
5.51K
Check_Proxy.js27.4 KB
基于TLSClient的多重功能 - Check_Proxy.js
作为面向 ProxyIP 场景的 Cloudflare Worker 检测器，它放弃了传统基于
来判断该 IP 是否具备真正的 ProxyIP 反代能力。
相比只检查
因此作为纯 Workers 实现检测 ProxyIP 的唯一入口。
作为面向 ProxyIP 场景的 Cloudflare Worker 检测器，它放弃了传统基于
/cdn-cgi/trace 的描述型判断方式，转而使用内嵌 TlSClient 进行真实链路验证: 直接让候选入口 → 实际由 Cloudflare CDN 反代的域名 → 通过真实 SNI/Host + TLS 握手 + HTTP → 请求
来判断该 IP 是否具备真正的 ProxyIP 反代能力。
相比只检查
/cdn-cgi/trace 是否存在、响应格式是否符合预期的描述型方法， Check_Proxy 更接近真实使用场景，能明显减少“有 trace 但不能用”的误判，把检测逻辑从表面特征识别提升到实际功能验证，正确率高达100%。因此作为纯 Workers 实现检测 ProxyIP 的唯一入口。
测试入口: https://pr-apis.ekt.me/probe?candidate=118.34.215.56:34042- ❤ 6
- 🎉 2
- 👏 1
Post #821
5.08K
Notif 💬 HTTPSMini.jsHTTPSMini_v1.js26 KB
v1 版本修复以下内容∶
① 原先会无条件的将IP/IPv6作为SNI转发到代理服务器，导致部分代理无法正常使用。
② 加入忽略TLS发出的警告，兼容部分域名入口的代理。
已通过随机取量500+测试样本的严格基准测试。
① 原先会无条件的将IP/IPv6作为SNI转发到代理服务器，导致部分代理无法正常使用。
② 加入忽略TLS发出的警告，兼容部分域名入口的代理。
已通过随机取量500+测试样本的严格基准测试。
- ❤ 2
- 👍 1
Post #820
5.21K
Notif 💬 Softether.js
SSTP代理出站测试 日本🇯🇵教育网
vless://2523c510-9ff0-415b-9582-93949bfae7e3@animal.nuaa.tech:2083/?type=ws&encryption=none&flow=&host=a.main-506.workers.dev&path=%2Fsstp%3A%2F%2Fpublic-vpn-58.opengw.net%3A443%3Fed%3D2560&security=tls&sni=a.main-506.workers.dev&fp=chrome&packetEncoding=xudp&ech=cloudflare-ech.com%2Bhttps%3A%2F%2F223.5.5.5%2Fdns-query#SSTP
- 👍 3
- ❤ 1
- 👎 1
- 👨💻 1
Post #819
5.56K
Softether.js13.2 KB
SoftEther.js 乃 VPANGTE 之战士重铸协议！
非那凡俗之 WS 至 TCP 之仆从，乃仿VPANGTE（日本大学之伟业）之狂战士实验！
其核心如奥丁之谋略：
• 于受限之 Workers 荒原重筑通讯战路
• 不倚赖那完整系统之网络长盾
• 在脚本之铁砧上锻造协议与转发
数据之路径如瓦尔哈拉之梯：
代码已铸就：
与普通 Worker 之奴仆有别：
普通奴仆:
WebSocket → connect() → 目标
SoftEther.js:
WebSocket → 协议解析 → 虚拟战路 → 手工 IP/TCP 铸甲 → 目标
它非仅搬运字节之流，乃在 Worker 之厅堂模拟部分网络之栈，如托尔之锤！
功能之战：
适合：
• VPANGTE 思路之复现
• Workers 协议之试炼
• 边缘战路重建之研究
• PPP / IP / TCP 脚本实现之参考
一言以蔽之：
重点非单一之协议，乃 VPANGTE 式之协议重组：于 Cloudflare Workers 之荒原，手工重铸可用之通讯战路！
非那凡俗之 WS 至 TCP 之仆从，乃仿VPANGTE（日本大学之伟业）之狂战士实验！
其核心如奥丁之谋略：
• 于受限之 Workers 荒原重筑通讯战路
• 不倚赖那完整系统之网络长盾
• 在脚本之铁砧上锻造协议与转发
数据之路径如瓦尔哈拉之梯：
VLESS over WebSocket → 战士 → 虚拟战路 → PPP/IP/TCP → 荣耀目标
代码已铸就：
• VLESS 之解析
• UUID 之试炼
• 目标地址/港口之掠夺
• 虚拟战路之建立
• PPP 之谈判（LCP / PAP / IPCP）
• 夺取虚拟 IP 之财富
• 手工锻造 IPv4/TCP 之矛
• SYN / ACK / PSH / FIN 之战吼
• 分段、序号、校验和之计算
• WebSocket 与远端 TCP 之双向桥梁
与普通 Worker 之奴仆有别：
普通奴仆:
WebSocket → connect() → 目标
SoftEther.js:
WebSocket → 协议解析 → 虚拟战路 → 手工 IP/TCP 铸甲 → 目标
它非仅搬运字节之流，乃在 Worker 之厅堂模拟部分网络之栈，如托尔之锤！
功能之战：
普通WS奴仆 SoftEther.js
VLESS解析 ✓ ✓
WebSocket接入 ✓ ✓
直接TCP转发 ✓ 非核心
虚拟战路谈判 ✗ ✓
PPP处理 ✗ ✓
IPv4/TCP铸甲 ✗ ✓
协议研究之荣耀 低 高
适合：
• VPANGTE 思路之复现
• Workers 协议之试炼
• 边缘战路重建之研究
• PPP / IP / TCP 脚本实现之参考
一言以蔽之：
重点非单一之协议，乃 VPANGTE 式之协议重组：于 Cloudflare Workers 之荒原，手工重铸可用之通讯战路！
- 🥰 2
- 👏 2
- 😁 2
- ❤ 1
Post #818
4.68K
Notif 💬 HTTPSMini.js
HTTPS代理出站测试 日本🇯🇵教育网
vless://2523c510-9ff0-415b-9582-93949bfae7e3@animal.nuaa.tech:2053/?type=ws&encryption=none&flow=&host=htps.enkelte.ggff.net&path=%2F%3Fhttps%3A%2F%2Fsecure.mse.waseda.ac.jp%3A443&security=tls&sni=htps.enkelte.ggff.net&fp=random#🇯🇵 日本 | 教育网
- ❤ 6
- 🎉 4
Post #817
4.97K
HTTPSMini.js25.2 KB
超级振奋地宣布一个激动人心的新篇章！我们自豪地推出了 TLSClientMini 与 HTTPSMini——这是专为 Worker 生态量身打造的极致轻量级解决方案，完美对齐我们追求敏捷与卓越的使命！🚀
TLSClientMini 是我们战略聚焦的结晶：从完整的 TLSClient 中精心提炼出核心精髓，仅保留 TLS 1.2/1.3、关键 AEAD 套件及握手收发等 Worker 场景的“黄金路径”。我们的愿景绝非构建庞大的浏览器级堆栈，而是以极致的精简体积，赋能那些原生路径无法触达的特殊 HTTPS 代理场景（如纯 IP 代理或需灵活跳过证书验证的机遇）。通过剔除冗余，我们成功将“连接、握手、传输”这一核心价值链优化至极致，显著降低了维护成本并释放了创新潜能。
与此同时，HTTPSMini 作为 HTTPS.js 与 TLSClientMini 的战略性融合，重新定义了最小化 HTTPS CONNECT Worker 的标准。它专为建立代理连接并转化为隧道转发而设计，巧妙部署双轨驱动引擎：
1️⃣ 极速通道：利用原生 secureTransport:on 机制，为标准证书代理场景提供无延迟的性能巅峰。
2️⃣ 兼容通道：通过“原始 TCP → TLSClientMini 握手 → 发送 CONNECT”的灵活路径，完美覆盖需跳过证书验证的特殊需求。
我们确保在标准场景中零损耗，同时在特殊场景中补齐原生能力，实现真正的全面赋能。
我们的执行蓝图清晰而有力：
✨ 精准裁剪 Mini 版，锁定 TLS 1.2/1.3、记录层及核心握手逻辑，涵盖 TLS_AES_128_GCM_SHA256、TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 等关键套件。
✨ 打造极简 HTTPS CONNECT 入口：智能解析代理地址，动态决策原生或 Insecure 路径，握手成功后即刻发送 CONNECT，并在收到 200 响应后启动双向数据流转发。
✨ 最终整合为单文件 Worker，实现部署效率的飞跃。
总结而言，TLSClientMini 攻克了特殊代理握手的战略高地，而 HTTPSMini 则将其无缝接入代理工作流。两者的强强联合，不仅保留了原生快路径的卓越性能，更补齐了兼容路径的最后一块拼图。让我们共同拥抱这一技术跃迁，开启高效连接的新纪元！
TLSClientMini 是我们战略聚焦的结晶：从完整的 TLSClient 中精心提炼出核心精髓，仅保留 TLS 1.2/1.3、关键 AEAD 套件及握手收发等 Worker 场景的“黄金路径”。我们的愿景绝非构建庞大的浏览器级堆栈，而是以极致的精简体积，赋能那些原生路径无法触达的特殊 HTTPS 代理场景（如纯 IP 代理或需灵活跳过证书验证的机遇）。通过剔除冗余，我们成功将“连接、握手、传输”这一核心价值链优化至极致，显著降低了维护成本并释放了创新潜能。
与此同时，HTTPSMini 作为 HTTPS.js 与 TLSClientMini 的战略性融合，重新定义了最小化 HTTPS CONNECT Worker 的标准。它专为建立代理连接并转化为隧道转发而设计，巧妙部署双轨驱动引擎：
1️⃣ 极速通道：利用原生 secureTransport:on 机制，为标准证书代理场景提供无延迟的性能巅峰。
2️⃣ 兼容通道：通过“原始 TCP → TLSClientMini 握手 → 发送 CONNECT”的灵活路径，完美覆盖需跳过证书验证的特殊需求。
我们确保在标准场景中零损耗，同时在特殊场景中补齐原生能力，实现真正的全面赋能。
我们的执行蓝图清晰而有力：
✨ 精准裁剪 Mini 版，锁定 TLS 1.2/1.3、记录层及核心握手逻辑，涵盖 TLS_AES_128_GCM_SHA256、TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 等关键套件。
✨ 打造极简 HTTPS CONNECT 入口：智能解析代理地址，动态决策原生或 Insecure 路径，握手成功后即刻发送 CONNECT，并在收到 200 响应后启动双向数据流转发。
✨ 最终整合为单文件 Worker，实现部署效率的飞跃。
总结而言，TLSClientMini 攻克了特殊代理握手的战略高地，而 HTTPSMini 则将其无缝接入代理工作流。两者的强强联合，不仅保留了原生快路径的卓越性能，更补齐了兼容路径的最后一块拼图。让我们共同拥抱这一技术跃迁，开启高效连接的新纪元！
- 👍 10
- ❤ 5
- 😍 4
- 👏 1
Post #814
4.83K
Notif 💬 HTTPS.js
HTTPS.js 重点说明
secureTransport 只控制 Worker → 代理 这一跳是否使用 TLS：
· on → 强制 TLS（即 HTTPS 代理）
· off → 明文（即 HTTP 代理）
没有“跳过 TLS”的接口。若需要自定义 TLS 行为（如跳过验证），必须在 Worker 内自己实现 TLS Client。
---
TLS 使用限制（公开代码）
若要正常使用 HTTPS 代理（secureTransport: 'on'），代理地址必须是 domain:port，且满足：
· 证书可正常校验
· 非自签
· 域名与证书匹配
若只有 IP:PORT，无法直接作为公开代码中可用的 HTTPS 代理。
---
反查域名（从 IP 找可用域名）
1. 资产平台：FOFA / Shodan / ZoomEye 查看证书 CN/SAN、历史域名。
2. 证书信息：直接连接目标端口，提取 CN / SAN。
3. 反向 DNS：PTR 记录（辅助线索）。
4. 被动 DNS：查询 IP 历史解析过的域名。
5. 指纹判断：Server 头、标题、TLS 指纹等。
6. 同证书扩展：根据证书指纹/主体反查其他域名。
注意：反查出的域名需人工验证——是否解析到该 IP、证书是否匹配、是否确实是代理入口。
---
代理 IP 初筛（基于 MaxMind ASN）
1. 下载 MaxMind ASN 库
2. 筛选 ASN 组织名含关键词：
· 教育：univ / university / college / school / institute 等
· 政府：gov / government / ministry / department 等
3. 提取对应网段作为候选 IP 范围
⚠️ 此方法仅作初筛，易误判/漏判，需人工复核。
---
易错点 & 结论
· secureTransport 只有 on/off，无“跳过 TLS”选项。
· 公开代码中 HTTPS 代理必须为 domain:port + 正常证书。
· 从 IP 获取可用域名需多源反查 + 人工验证。
· ASN 关键词筛选只能粗筛候选，不能直接作为最终结果。
secureTransport 只控制 Worker → 代理 这一跳是否使用 TLS：
· on → 强制 TLS（即 HTTPS 代理）
· off → 明文（即 HTTP 代理）
没有“跳过 TLS”的接口。若需要自定义 TLS 行为（如跳过验证），必须在 Worker 内自己实现 TLS Client。
---
TLS 使用限制（公开代码）
若要正常使用 HTTPS 代理（secureTransport: 'on'），代理地址必须是 domain:port，且满足：
· 证书可正常校验
· 非自签
· 域名与证书匹配
若只有 IP:PORT，无法直接作为公开代码中可用的 HTTPS 代理。
---
反查域名（从 IP 找可用域名）
1. 资产平台：FOFA / Shodan / ZoomEye 查看证书 CN/SAN、历史域名。
2. 证书信息：直接连接目标端口，提取 CN / SAN。
3. 反向 DNS：PTR 记录（辅助线索）。
4. 被动 DNS：查询 IP 历史解析过的域名。
5. 指纹判断：Server 头、标题、TLS 指纹等。
6. 同证书扩展：根据证书指纹/主体反查其他域名。
注意：反查出的域名需人工验证——是否解析到该 IP、证书是否匹配、是否确实是代理入口。
---
代理 IP 初筛（基于 MaxMind ASN）
1. 下载 MaxMind ASN 库
2. 筛选 ASN 组织名含关键词：
· 教育：univ / university / college / school / institute 等
· 政府：gov / government / ministry / department 等
3. 提取对应网段作为候选 IP 范围
⚠️ 此方法仅作初筛，易误判/漏判，需人工复核。
---
易错点 & 结论
· secureTransport 只有 on/off，无“跳过 TLS”选项。
· 公开代码中 HTTPS 代理必须为 domain:port + 正常证书。
· 从 IP 获取可用域名需多源反查 + 人工验证。
· ASN 关键词筛选只能粗筛候选，不能直接作为最终结果。
- 👍 5
- 🎉 1
Post #813
4.48K
Notif 💬 HTTPS.js
对于部署出来不通的情况，到Workers项目设置里修改兼容时间。
- ❤ 1
Post #812
4.83K
Post #811
5.74K
Notif 💬 HTTPS.js
HTTPS代理出站测试 美国🇺🇸教育网
vless://2523c510-9ff0-415b-9582-93949bfae7e3@animal.nuaa.tech:2053/?type=ws&encryption=none&flow=&host=htps.enkelte.ggff.net&path=%2F%3Fhttps%3A%2F%2Fdebrowser.umassmed.edu%3A443&security=tls&sni=htps.enkelte.ggff.net&fp=random#🇺🇸 美国 | 教育网
- ❤ 4
About this channel
- How can I read @enkelte_notif without a Telegram account?
- TGViewer shows the public web preview Telegram publishes for Notif 💬: recent posts, photos, videos and the subscriber count, with no app, login or account.
- How many subscribers does Notif 💬 have?
- Notif 💬 (@enkelte_notif) has 4.54K subscribers on Telegram, refreshed roughly every 30 minutes.
- Does Notif 💬 know I viewed it here?
- No. Public channel previews carry no viewer identity, and TGViewer has no accounts or tracking of what you look up.