飘在云端

东西南北,海角天涯

· 随笔 · · 471次浏览

subconverter 支持 https 代理写法格式(base64)

更新:2024-4-2 ,增加一些补充说明,当时是意外发现,写的比较随意,有些小伙伴私信我一些具体细节,现已增加说明和例子


意外发现 subconverter 订阅转换 隐性 支持 https 代理,即 clash https + tls,转换后的 clash 格式如下

  - {name: example, server: example.com, port: 123, type: http, username: admin, password: 12345, tls: true, skip-cert-verify: false}

它的链接格式是

https://base64(用户名:密码@服务器的域名或ip:端口)
https://base64(admin:12345@example.com:123)
base64 编码后为:https://YWRtaW46MTIzNDVAZXhhbXBsZS5jb206MTIz

好像没有参数能修改节点名,输出的节点名字恒定为 服务器地址:端口

尝试转换后追加参数 &remarks=example 或者在链接格式后面追加 #URLEncode(example) 无效

如何使用:拼接后链接,让它能被 Clash 识别使用,必须再次 base64(https://base64(用户名:密码@服务器的域名或ip:端口)),作为 base64 形式的订阅源来转换到 clash 能使用的格式

具体来说:
把每个第一次 base64 编码的 http 拼接的链接单独放一行,如

https://YWRtaW46MTIzNDVAZXhhbXBsZS5jb206MTIz
https://YWRtaW46MTIzNDVAZXhhbXBsZS5jb206MTIz
https://YWRtaW46MTIzNDVAZXhhbXBsZS5jb206MTIz
https://YWRtaW46MTIzNDVAZXhhbXBsZS5jb206MTIz
https://YWRtaW46MTIzNDVAZXhhbXBsZS5jb206MTIz

最后根据通用约定标准,一般为 base64(base64 是目前现行的事实标准/强制标准,现行所有客户端必定支持) 规范对所有节点进行一次 base64(或者 sip008 / 其他标准),产生只有一行内容的二次base64编码的文本,然后放到某个服务器上面,客户端输入这个在内网或公网能访问到该内容的 url

如放到一个 对外提供 web 服务的网站提供访问,https://api.0z.gs/114514/1919810/2024.txt

2024.txt里面就是对所有节点 base64 编码后的的内容,在这里就是

aHR0cHM6Ly9ZV1J0YVc0Nk1USXpORFZBWlhoaGJYQnNaUzVqYjIwNk1USXoKaHR0cHM6Ly9ZV1J0YVc0Nk1USXpORFZBWlhoaGJYQnNaUzVqYjIwNk1USXoKaHR0cHM6Ly9ZV1J0YVc0Nk1USXpORFZBWlhoaGJYQnNaUzVqYjIwNk1USXoKaHR0cHM6Ly9ZV1J0YVc0Nk1USXpORFZBWlhoaGJYQnNaUzVqYjIwNk1USXoKaHR0cHM6Ly9ZV1J0YVc0Nk1USXpORFZBWlhoaGJYQnNaUzVqYjIwNk1USXo=

订阅转换输入 https://api.0z.gs/114514/1919810/2024.txt 进行转换,最终输出 http 节点信息到 clash 内核客户端,并使用

直接使用拼接好的格式 https://base64(用户名:密码@服务器的域名或ip:端口) 是无法被 subconverter 转换的,也不支持单独输入第一次编码的 http 格式节点信息

https 代理应该是境内中转使用的,跨境应该是使用了其他协议再次封装,挺少见这么搞的,并且这样是无法支持 udp 的

评论 (0条)