Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[nginx] Websocket upgrade not working for non-standard HTTPS port #2944

Closed
timn opened this issue Mar 27, 2023 · 4 comments
Closed

[nginx] Websocket upgrade not working for non-standard HTTPS port #2944

timn opened this issue Mar 27, 2023 · 4 comments

Comments

@timn
Copy link

timn commented Mar 27, 2023

Describe the issue you are experiencing

When using the nginx proxy with a non-standard HTTPS port (e.g., 8135 instead of 443) configured via the port section of the add-on config, websocket upgrade will not work. This causes issues with other add-ons, e.g., deconz or ESPHome (cannot open frontend of former, latter will just show a black frame for actions such as validate).

The problem is that the proxy_set_header Host directive does not name a port, and thus the default is being used.

The solution would be to make the port configuration accessible in the add-on via bashio (e.g., add it as a section to options.json) and use it for a macro such as %%HTTPS_PORT%% similar to %%HA_PORT%%.

What type of installation are you running?

Home Assistant OS

Which operating system are you running on?

Home Assistant Operating System

Which add-on are you reporting an issue with?

NGINX Home Assistant SSL proxy

What is the version of the add-on?

3.2.0

Steps to reproduce the issue

  1. Access Home Assistant remotely over TLS proxy on non-standard port (not 443)
  2. Install ESPHome addon
  3. Validate a chart
  4. This would simply show an empty black frame instead of the compiler output

System Health information

System Information

version core-2023.3.6
installation_type Home Assistant OS
dev false
hassio true
docker true
user root
virtualenv false
python_version 3.10.10
os_name Linux
os_version 5.15.90
arch aarch64
timezone Europe/Berlin
config_dir /config
Home Assistant Community Store
GitHub API ok
GitHub Content ok
GitHub Web ok
GitHub API Calls Remaining 5000
Installed Version 1.31.0
Stage running
Available Repositories 1249
Downloaded Repositories 17
Home Assistant Cloud
logged_in true
subscription_expiration redacted
relayer_connected true
remote_enabled false
remote_connected false
alexa_enabled false
google_enabled true
remote_server eu-central-1-0.ui.nabu.casa
can_reach_cert_server ok
can_reach_cloud_auth ok
can_reach_cloud ok
Home Assistant Supervisor
host_os Home Assistant OS 9.5
update_channel stable
supervisor_version supervisor-2023.03.2
agent_version 1.4.1
docker_version 20.10.22
disk_total 113.9 GB
disk_used 49.3 GB
healthy true
supported true
board odroid-n2
supervisor_api ok
version_api ok
installed_addons NGINX Home Assistant SSL proxy (3.2.0), deCONZ (6.18.0), SSH & Web Terminal (13.1.0), Mosquitto broker (6.2.0), ESPHome (2023.3.2)
Dashboards
dashboards 1
resources 9
views 9
mode storage
Recorder
oldest_recorder_run January 3, 2023 at 11:36
current_recorder_run March 27, 2023 at 10:25
estimated_db_size 6431.23 MiB
database_engine sqlite
database_version 3.38.5

Anything in the Supervisor logs that might be useful for us?

The supervisor would have errors such as the following for ESPHome:

23-03-27 21:26:45 ERROR (MainThread) [supervisor.api.ingress] Ingress error: 403, message='Invalid response status', url=URL('http:https://172.30.32.1:63398/validate')
23-03-27 21:26:50 ERROR (MainThread) [supervisor.api.ingress] Ingress error: 403, message='Invalid response status', url=URL('http:https://172.30.32.1:63398/ace')
23-03-27 21:26:55 ERROR (MainThread) [supervisor.api.ingress] Ingress error: 403, message='Invalid response status', url=URL('http:https://172.30.32.1:63398/compile')

Anything in the add-on logs that might be useful for us?

No response

Additional information

A workaround that I'm currently using is to add a file /share/nginx_proxy_default_fix_ingress.conf with the following content:

location /api/hassio_ingress {
    proxy_pass http:https://homeassistant.local.hass.io:8123/api/hassio_ingress;
    proxy_set_header Host $host:<PORT>;
    proxy_redirect http:https:// https://;
    proxy_http_version 1.1;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;
}

(with <PORT> replaced by the port configured in the addons configuration ports section).

@danswett
Copy link

I’m having this issue as well since a recent update.

@denes44
Copy link

denes44 commented Apr 21, 2023

I also had this problem after I changed from native HTTPS to nginx, the terminal screens was blank for the esphome addon.
Nginx is running on a separate machine (VM) from Home Assistant.
Addig the port number to the nginx config seemed to solve the issue:

location / {
	proxy_set_header 			X-Forwarded-For   $proxy_add_x_forwarded_for;
	proxy_set_header 			X-Forwarded-Proto $scheme;
	proxy_set_header                   	Host $host:5101;
	proxy_set_header                   	X-Real-IP $remote_addr;
	proxy_set_header			Upgrade $http_upgrade;
	proxy_set_header			Connection "upgrade";
	proxy_pass                         	http:https://192.168.2.101:8123/;
	add_header 				X-Frame-Options SAMEORIGIN;
}

@github-actions
Copy link

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@github-actions
Copy link

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@github-actions github-actions bot added the stale label Jun 21, 2023
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Jun 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants