App connection not possible if evcc server is behind a (TLS) proxy
Describe the bug
I have evcc running in docker, exposed behind my traefik reverseproxy over port 443. In the app, I cannot access this server. When trying to type the address in manually (https://evcc.myserver.com) it adds an http:// automatically (http://https://evcc.myserver.com). This cannot work obviously and looks like a bug? I can access the web interface just fine via the https url.
Steps to reproduce
- run evcc behind reverse proxy with tls enabled
- try to access evcc via the app starting with https://...
Configuration details
I have just the demo config file enabled right now.
Log details
There are no logs for this.
What type of operating system or environment does evcc run on?
Docker container
External automation
- [x] I have made sure that no external automation like HomeAssistant or Node-RED is active or accessing any of the mentioned devices when this issue occurs.
Nightly build
- [x] I have verified that the issue is reproducible with the latest nightly build
Version
evcc version 0.207.5
In the config ui go to network settings and switch it to https
Ok it will not work because config is Blocked in Demo... but it will work as soon as you run your own config....
Is this in the webui? This works just fine. If this is the app, I cannot find this setting (or settings in general). In the app, I can only search for my instance (not found) or type it in manually. When trying to type it in manually, the http://https:// thing happens. But I just tested typing "evcc.myserver.com" and it works, even though it adds "http://" automatically and it would be the wrong. So its just confusing and could be improved UI wise.
The settings are only in the web UI.. and will only work with your own config... starting evcc with no config you will be redirected to your config... set the protocol to https enter the hostname...
The Demo is a fixed config that will only work on localhost..
I guess not many People tried putting the demo behind their reverse proxy..
@naltatis I browsed the documentation ... and found nothing regarding reverse proxies so documenting the Network Settings in the UI would be helpful...
I just set it without thinking much about it...
https://github.com/evcc-io/app
https://github.com/evcc-io/app
You're right, this is probably the wrong repo for my issue then...
The Problem is more with the Missmatching Schema setting when running the demo in your evcc instance I can Set.. http:// https:// and nothing and it always works.. (maybe du to cloudflare doing the https redirect..)
Just try it start evcc with no config ... in the ui enable Expermimental ui config and change Network to:
then try the app again and you will see the start configuration screen in the app
The http/https setting in the web UI should not have any affect on the app server setup behavior. Looks like a bug in our entry form.
It might be relevant to know that not every reverse proxy doesn't work:
- In my LAN at home I use Caddy as a reverse proxy. When trying to connect to it via the evcc app, I also get the error mentioned above.
- When not at home, the same FQDN connects to an NGINX server in the internet, which then itself reverse proxies requests through a VPN to the Caddy server mentioned above. Now the funny thing is, that in that case the evcc app has no problem at all connecting to the server. The relevant NGINX-section looks like this:
location / { proxy_pass https://172.16.XXX.XXX/; proxy_ssl_name $host; proxy_ssl_server_name on; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $remote_addr; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $connection_upgrade; }
Notable differences are:
- the traefik server as well as Caddy are implemented in Go and most likely use the same TLS implementation. Maybe there are some significant differences in the TLS implementation or available ciphers.
With https://github.com/evcc-io/evcc/pull/25285 being merged in evcc we can now improve auto discovery.
The mDNS records now always include internal_url and may include external_url. Currently we construct the url programmatically from parts. With the updated mDNS announcement we should 1) use external_url if exists, 2) use internal_url if exists and finally (old evcc instances) fall back to our existing url construction logic.
With this change it's possible to specify a https url in your evcc instance (as external_url) and have apps discover this correctly. We'll also update the linux image to set external url by default to the https caddy reverse proxy endpoint.
Note: Internal and external url are not intended to be used as parallel, network-dependent, fallback-connection options (like in home assistant or loxone uses it).