更新：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 的