Help Needed for Production Reverse Proxy Setup

[baba-dev]

Hello, I have searched the forums, Issues, Reddit and Official Documentations for any information on how to reverse-proxy Open WebUI via Nginx.

Any assistance would be greatly appreciated. It seems there are JS errors when you force rewrite domain name via nginx.

[baba-dev]

Here is my existing Nginx Configuration:

    location /chatgpt {
        sub_filter '"/_app/' '"/chatgpt/_app/'; # Adding a rewrite rule for /_app/ based links.
        sub_filter '"/themes/' '"/chatgpt/themes/'; # Similar rewrite rule for themes based on console errors.
        sub_filter_once off;
        rewrite /chatgpt/(.*) /$1 break;
        proxy_pass http://192.168.173.252:8080;
    }

    location /chatgpt/api {
        rewrite /chatgpt/(.*) /$1 break;
        proxy_buffering off;
        proxy_set_header Origin '';
        proxy_set_header Referer '';
        proxy_pass http://192.168.173.252:8080/api;
    }

    location /chatgpt/api/v1 {
        rewrite /chatgpt/(.*) /$1 break;
        proxy_pass http://192.168.173.252:8080/api/v1;
    }

    location /chatgpt/themes {
        rewrite /chatgpt/(.*) /$1 break;
        proxy_pass http://192.168.173.252:8080/themes;
    }

[baba-dev]

Works on its Subdomain using the below config:

server {
   listen 80;
   listen [::]:80;
   server_name chatgpt.local;

location / {
  proxy_pass http://192.168.173.252:8080;
}

location /ollama/api {
  proxy_buffering off;
  proxy_set_header Origin '';
  proxy_set_header Referer '';
  proxy_pass http://192.168.173.252:8080/api;

}

location /api/v1 {
 proxy_pass http://192.168.173.252:8080/api/v1;
}
}

[justinh-rahb]

Given the need to make the entire backend application accessible under /chatgpt/ to the outside world without the backend being aware of this URL base path, you can simplify the NGINX configuration. The primary goal here is to prepend the /chatgpt path segment for external users, while internally directing requests as if they were made to the root path /.

Here's a streamlined approach to meet these requirements:

Simplified NGINX Configuration

This configuration ensures all requests that start with /chatgpt/ are internally redirected to the root path of the backend application. It avoids specifying multiple locations for different backend paths, treating all requests uniformly.

location /chatgpt/ {
    # Rewrite the incoming request by removing the /chatgpt prefix
    rewrite ^/chatgpt/(.*)$ /$1 break;

    # Proxy the modified request to the backend application
    proxy_pass http://192.168.173.252:8080/;

    # Optional: Set headers that might be required by the backend or for compliance with CORS, etc.
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;

    # Handle WebSocket upgrades if your application uses WebSockets
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

Key Points

• Unified Handling: This configuration doesn't differentiate between /chatgpt/api, /chatgpt/api/v1, or any other specific paths. Instead, it treats all requests starting with /chatgpt/ in the same manner, rewriting them to remove the /chatgpt prefix before proxying to the backend. This means that a request to http://yourserver/chatgpt/api/v1/resource will be proxied to http://192.168.173.252:8080/api/v1/resource.

• Simplified Configuration: By not dividing the configuration into multiple specific locations for API paths, themes, etc., maintenance becomes simpler. This approach assumes that the backend application can handle all requests from the root path and that there's no need for external paths to differ in handling from the NGINX's perspective.

• Backend Transparency: The backend application receives requests as if they were made directly to its root path, with no knowledge of the /chatgpt prefix. This setup meets the requirement for the backend to be "none the wiser" about the URL path modifications made by NGINX.

• WebSocket Support: If your application uses WebSockets, the additional headers Upgrade and Connection "upgrade" are crucial for supporting WebSocket connections through NGINX.

This configuration approach should meet the requirement of making the backend application accessible under /chatgpt/ from the internet, with a setup that's straightforward to manage and does not necessitate the backend to be aware of the external path prefix.

[baba-dev]

Thank you. So I tried your config for subpath serving. Still stuck on similar errors:

[justinh-rahb]

@baba-dev ruled out cache issue? Ctrl + Shift + R or disabling cache in dev tools should clear that.

[baba-dev]

Yes, Tried in incognito as well.

[baba-dev]

I Have noticed yet another issue, with its Subdomain specific configuration for Nginx, The downloaded models do not show up on the proxied frontend :

The Domain Specific Configuration in reference to:

server {
   listen 80;
   listen [::]:80;
   server_name chatgpt.local;

location / {
  proxy_pass http://192.168.173.252:8080;
}

location /ollama/api {
  proxy_buffering off;
  proxy_set_header Origin '';
  proxy_set_header Referer '';
  proxy_pass http://192.168.173.252:8080/api;
}

location /api/v1 {
 proxy_pass http://192.168.173.252:8080/api/v1;
}
}

I do have models working and running when I access the default address:

Image 2:

[baba-dev]

A Hint to as why it may not be working when proxied, There are some JS errors in the browser window:

The Server Connection Fails line seems to be the main cause. On a normal acess to IP, There are no errors in console window.

[lesca]

Hello,
this is a very good discussion to make webui work behind https proxy.

I've tested in my environment, configuration as below:

    location /chatgpt/ {
        proxy_buffering off;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Accept-Encoding "";
        sub_filter '"/_app/' '"/chatgpt/_app/';
        sub_filter '"/themes/' '"/chatgpt/themes/';
        sub_filter_once off;

        # proxy
        proxy_pass http://192.168.2.2:3000/;
    }

Screenshot below shows it works at first, but when it comes to "version.json" request, it fails. Look into the headers, it seems the request URL is wrong. I suspect the loaded JS code doesn't respect the custom path "/chatgpt", instead, it just appends its path (_app) after the hostname (or IP).

To be short:

• Wrong: https://u.silkdiy.cn/_app/version.json
• Correct: https://u.silkdiy.cn/chatgpt/_app/version.json

Then, I turned to below configuration using the root virtual directory ("/") for proxing. This works without problem.

    location / {
        proxy_buffering off;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Accept-Encoding "";
        # sub_filter '"/_app/' '"/chatgpt/_app/';
        # sub_filter '"/themes/' '"/chatgpt/themes/';
        # sub_filter_once off;

        # proxy
        proxy_pass http://192.168.2.2:3000/;
    }

My guess is something needs to be changed in the JS code to make it work with customized virtual directory of reversed proxy.

[ProjectMoon]

I"m trying to expose Open WebUI via nginx. It works fine for the UI and stuff, but the proxied ollama API has issues with event streaming. I've narrowed it down to nginx itself being the problem, and turned off proxy_buffering, but it still does not seem to chunk correctly. Any ideas?

    location /ollama/api {
        proxy_set_header Connection "";
        proxy_http_version 1.1;
        proxy_request_buffering off;
        chunked_transfer_encoding off;
        proxy_buffering off;
        proxy_max_temp_file_size 0;
        proxy_cache off;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_pass http://localhost:11435/ollama/api;
    }

[EmilSchurr]

I've had the same issue, my deployment being ollama installed directly on the VM and the Open WebUI installed as a docker container. What fixed it was changing
location /ollama/api
to
location /api

[ProjectMoon]

Could you share a bit more about this? Maybe the config block? Are you mapping /api to /ollama/api for example?

[mila76]

Hi, setup a reverse proxy (with Nginx Proxy Manager) for https WebUI access.. Work but not very well
All the chat dont "stream" (i have block of response) anymore or dont work at all

I can't figure out wich options or modification can made to work with the reverse proxy.
I'm not an expert of reverse proxy so any help is welcome. Thanks

[mila76]

For reference the only missing option (added on the advance tab) is proxy_buffering off;
Thanks for @EmilSchurr for sharing

[sprklinginfo]

can't use root to proxy to the WebUI container as I have other applications running. anyone have a working NGINX reverse proxy from a sub-directory in this case? thanks!

[EmilSchurr]

This doesn't seem to be the problem from the OP, but if anyone is still having trouble with a reverse proxy and getting the streaming to work correctly, this is the right config:

server {
    server_name subdomain.yourdomain.com;
    location / {
        proxy_pass http://10.10.3.10:8080;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_buffering off;
        proxy_set_header Origin '';
        proxy_set_header Referer '';
    }
    location /api {
        proxy_http_version 1.1;
        proxy_buffering off;
        proxy_set_header Origin '';
        proxy_set_header Referer '';
        proxy_pass http://10.10.3.10:8080/api;
    }
    location /api/v1 {
        proxy_pass http://10.10.3.10:8080/api/v1;
    }
    listen 443 ssl;
}

[ProjectMoon]

Is this specifically for Open WebUI, or the ollama process itself? Open WebUI proxies ollama under a /ollama endpoint, unless I'm missing something?

[sprklinginfo]

thanks for sharing @EmilSchurr. I have Ollama installed on a ubuntu 22 VM directly and it can be accessed from "http://127.0.0.1:11434". I installed the open webui with the following docker command: $ docker run -d --network=host -v open-webui:/app/backend/data -e OLLAMA_BASE_URL=http://127.0.0.1:11434 --name open-webui --restart always ghcr.io/open-webui/open-webui:main.
On the VM I configured the reverse proxy like the following blocks by incorporating yours, wishing to access with a subdirectory as I have other applications running on the root of Nginx and some other applications too.

server {
    listen 443 ssl;
    server_name subdomain.exmple.com;
    root /var/www/web-app/public;
    index index.html index.htm index.php

    location /chat {
        proxy_pass http://127.0.0.1:8080;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_buffering off;
        proxy_set_header Origin '';
        proxy_set_header Referer '';
    }

 location /api {
        proxy_http_version 1.1;
        proxy_buffering off;
        proxy_set_header Origin '';
        proxy_set_header Referer '';
        proxy_pass http://127.0.0.1:8080/api;
    }
    location /api/v1 {
        proxy_pass http://127.0.0.1:8080/api/v1;
    }

  location / {
        try_files $uri $uri/ /index.php?$query_string;
    }
 location ~ \.php$ {
        try_files $uri =404;
        fastcgi_pass unix:/run/php/php8.1-fpm.sock;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }
    location ^~ /tools {
        alias /var/www/tools;
    }
}```. 
but got lots of 404 errors. 
![Snipaste_2024-05-07_14-27-56](https://github.com/open-webui/open-webui/assets/3521826/4684c0ed-c743-4fdc-821f-597e6f6cef47)