add HTTPS support for external controller

[khronosmoe]

The site http://yacd.haishan.me/ is served with HTTP not HTTPS is because many browsers block requests to HTTP resources from a HTTPS website. If you think it's not safe, you could just download the zip of the gh-pages, unzip and serve those static files with a web server(like Nginx).

In order to solve this, I make this commit to add HTTPS support for external controller. Config is as follows:

external-controller: 127.0.0.1:9090
external-ui: yacd
secret: ""
external-tls: true
tls-cert-file: path_to_cert
tls-key-file: path_to_key

[Dreamacro]

I think TLS offloading should be done by nginx or caddy, not on clash

[khronosmoe]

Check https://blog.thris.me/archives/cldash-https.html , it would be better to provide a direct https function for RESTful API and dashboard than to use nginx. Meanwhile, Surge now also supports.

[khronosmoe]

To make my point clear, it is overkill and complicated to use Nginx to reverse proxy both the RESTful API and static web dashboard, considering most use cases are very simple just a web hosting, which the golang build-in ServeTLS() function is enough. And this is an option, users can choose whether to use Nginx or built-in function.

[btwiuse]

The site http://yacd.haishan.me/ is served with HTTP not HTTPS is because many browsers block requests to HTTP resources from a HTTPS website. If you think it's not safe, you could just download the zip of the gh-pages, unzip and serve those static files with a web server(like Nginx).

In order to solve this, I make this commit to add HTTPS support for external controller. Config is as follows:

external-controller: 127.0.0.1:9090
external-ui: yacd
secret: ""
external-tls: true
tls-cert-file: path_to_cert
tls-key-file: path_to_key

My solution to the problem is to allow setting external-ui to a remote url, like

external-ui: https://clashboard.vercel.app

Instead of embedding static assets into the binary, it serves the web ui by reverse-proxying a remote url.

Pros:

• you don't have to manually download ui anymore
• you don't need to separately handle the ui directory when configuring nginx, caddy etc.
• no more https://webui -> http://clash problem, the webui is directly accessible from http://clash

Cons:

• needs external network access

You can try my fork at https://github.com/btwiuse/dash

I can make a pull request if this idea sounds good to you. @Dreamacro

[khronosmoe]

The site http://yacd.haishan.me/ is served with HTTP not HTTPS is because many browsers block requests to HTTP resources from a HTTPS website. If you think it's not safe, you could just download the zip of the gh-pages, unzip and serve those static files with a web server(like Nginx).

In order to solve this, I make this commit to add HTTPS support for external controller. Config is as follows:

external-controller: 127.0.0.1:9090
external-ui: yacd
secret: ""
external-tls: true
tls-cert-file: path_to_cert
tls-key-file: path_to_key

My solution to the problem is to allow setting external-ui to a remote url, like

external-ui: https://clashboard.vercel.app

Instead of embedding static assets into the binary, it serves the web ui by reverse-proxying a remote url.

Pros:

* you don't have to manually download ui anymore

* you don't need to separately handle the ui directory when configuring nginx, caddy etc.

* no more `https://webui -> http://clash` problem, the webui is directly accessible from `http://clash`

Cons:

* needs external network access

You can try my fork at https://github.com/btwiuse/dash

I can make a pull request if this idea sounds good to you. @Dreamacro

What is the connection between your Clash and the remote server? Is it unencrypted? By the way, it is not " wise " to make the controller public and I strongly believe that the ServeTLS() function is a good and simple way.

[btwiuse]

What is the connection between your Clash and the remote server? Is it unencrypted? By the way, it is not " wise " to make the controller public and I strongly believe that the ServeTLS() function is a good and simple way.

My fork of clash (called dash onward) allows loading the webui from a remote url like this

./clash -ext-ctl 127.0.0.1:9090 -ext-ui https://clashboard.vercel.app

When you visit http://127.0.0.1:9090, dash will start a reverse proxy with https://clashboard.vercel.app being the upstream url

Any requests not matching

• /version
• /logs
• /traffic
• /configs
• /proxies
• /rules
• /connections
• /providers/proxies

will fallback to the reverse proxy handler

This is effectively the same as serving the webui on the root path http://127.0.0.1:9090/, and does not require making the controller public.

https://clashboard.vercel.app does not have an associated clash backend and won't leak your private info to the public.

It is compiled from https://github.com/Dreamacro/clash-dashboard with no modification.

The only purpose is to provide static frontend assets to the reverse proxy.

You can also set it to http://yacd.haishan.me/, and visiting http://127.0.0.1:9090 will show the yacd webui

./clash -ext-ctl 127.0.0.1:9090 -ext-ui http://yacd.haishan.me/

Hope this clarifies some misunderstandings.

[khronosmoe]

This is effectively the same as serving the webui on the root path http://127.0.0.1:9090/, and does not require making the controller public. https://clashboard.vercel.app/ does not have an associated clash backend and won't leak your private info to the public.

Okay, I get it, but I'm not going to use it in my production. Considering that there are already static files like rulesets and mmdb under the .config folder, why not put the dashboard there too? I appreciate laggardkernel's brew formula