issue: Running v0.3.3 behind reverse proxy with HTTPS. CORS problems with tools and websockets #1215

New Issue

2025-11-11T14:40:18-06:00

GiteaMirror commented

2025-11-11 14:40:18 -06:00

Originally created by @leuchtetgruen on GitHub (Jun 12, 2024).

I'm running OpenWebUI behind a nginx reverse proxy like so:

server {
  root /var/www/html;
  index index.html;
  server_name sub.host.tld;

  location / {
	  proxy_pass       http://10.x.x.x:3000;
	  proxy_set_header Host      $host;
	  proxy_set_header X-Real-IP $remote_addr;
	  proxy_read_timeout 300;
	  proxy_connect_timeout 300;
	  proxy_send_timeout 300;
	  client_max_body_size 30M;
  }



    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/sub.host.tld/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/sub.host.tld/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}
server {
    if ($host = sub.host.tld) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


  server_name sub.host.tld;
    listen 80;
    return 404; # managed by Certbot

}

As of Open Web UI 0.3.3 I get CORS problems in Firefox and Safari (and presumably also other browsers):

XMLHttpRequest cannot load https://sub.host.tld/ws/socket.io/?EIO=4&transport=polling&t=P0BqzUV&sid=_eB-6h1IefgXZNMbAAAM due to access control
WebSocket connection to 'wss://sub.host.tld/ws/socket.io/?EIO=4&transport=websocket&sid=5YQM0bzbhVh9o2RGAAAY' failed: There was a bad response from the server.
Fetch API cannot load http://sub.host.tld/api/v1/tools/ due to access control checks.

This results in the UI not showing.

I'm running OpenWebUI in docker (docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main).

In v0.3.2 I still get the errors about the websockets (the one about the /api/v1/tools is not present) but the UI is showing and working.

Originally created by @leuchtetgruen on GitHub (Jun 12, 2024). I'm running OpenWebUI behind a nginx reverse proxy like so: ``` server { root /var/www/html; index index.html; server_name sub.host.tld; location / { proxy_pass http://10.x.x.x:3000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_read_timeout 300; proxy_connect_timeout 300; proxy_send_timeout 300; client_max_body_size 30M; } listen 443 ssl; # managed by Certbot ssl_certificate /etc/letsencrypt/live/sub.host.tld/fullchain.pem; # managed by Certbot ssl_certificate_key /etc/letsencrypt/live/sub.host.tld/privkey.pem; # managed by Certbot include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot } server { if ($host = sub.host.tld) { return 301 https://$host$request_uri; } # managed by Certbot server_name sub.host.tld; listen 80; return 404; # managed by Certbot } ``` As of Open Web UI 0.3.3 I get CORS problems in Firefox and Safari (and presumably also other browsers): - XMLHttpRequest cannot load https://sub.host.tld/ws/socket.io/?EIO=4&transport=polling&t=P0BqzUV&sid=_eB-6h1IefgXZNMbAAAM due to access control - WebSocket connection to 'wss://sub.host.tld/ws/socket.io/?EIO=4&transport=websocket&sid=5YQM0bzbhVh9o2RGAAAY' failed: There was a bad response from the server. - Fetch API cannot load http://sub.host.tld/api/v1/tools/ due to access control checks. This results in the UI not showing. I'm running OpenWebUI in docker (`docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main`). In v0.3.2 I still get the errors about the websockets (the one about the /api/v1/tools is not present) but the UI is showing and working.

GiteaMirror closed this issue

2025-11-11 14:40:18 -06:00

GiteaMirror commented

2025-11-11 14:40:19 -06:00

@Testorakel commented on GitHub (Jun 12, 2024):

I have these problems too, but I use Apache.

@Testorakel commented on GitHub (Jun 12, 2024): I have these problems too, but I use Apache.

GiteaMirror commented

2025-11-11 14:40:19 -06:00

@KelvinCampelo commented on GitHub (Jun 12, 2024):

Hey mate,
I've had the same issue running Open WebUI under a reverse proxy with SSL. I was able to resolve it by adding the following line to the location directive in my Nginx configuration:

proxy_set_header X-Forwarded-Proto $scheme;

Explanation:

The Mixed Content error occurs when a secure HTTPS page attempts to request an insecure HTTP resource. Modern browsers block these requests to ensure security.

When Nginx acts as a reverse proxy, it terminates the SSL connection and forwards the request to the backend server (in this case, Open WebUI). The backend server needs to know the original protocol (HTTP or HTTPS) used by the client to generate URLs correctly.

By adding proxy_set_header X-Forwarded-Proto $scheme;, we inform the backend server of the original request scheme. This allows the backend server to generate URLs with the correct scheme, thus avoiding mixed content errors.

This small change ensures that all components in the application are aware of the original request's protocol, allowing them to behave correctly and securely.

Hope this helps!

@KelvinCampelo commented on GitHub (Jun 12, 2024): Hey mate, I've had the same issue running Open WebUI under a reverse proxy with SSL. I was able to resolve it by adding the following line to the location directive in my Nginx configuration: ```nginx proxy_set_header X-Forwarded-Proto $scheme; ``` # Explanation: The Mixed Content error occurs when a secure HTTPS page attempts to request an insecure HTTP resource. Modern browsers block these requests to ensure security. When Nginx acts as a reverse proxy, it terminates the SSL connection and forwards the request to the backend server (in this case, Open WebUI). The backend server needs to know the original protocol (HTTP or HTTPS) used by the client to generate URLs correctly. By adding proxy_set_header X-Forwarded-Proto $scheme;, we inform the backend server of the original request scheme. This allows the backend server to generate URLs with the correct scheme, thus avoiding mixed content errors. This small change ensures that all components in the application are aware of the original request's protocol, allowing them to behave correctly and securely. Hope this helps!

GiteaMirror commented

2025-11-11 14:40:20 -06:00