github-starred/open-webui
2
0
Fork 0
mirror of https://github.com/open-webui/open-webui.git synced 2026-08-30 17:25:30 -05:00
Code Issues 2.4k Packages Projects Releases 129 Wiki Activity

[GH-ISSUE #18030] issue: Web Search fails for local SearXNG with self-signed cert (requests missing verify=False) #18469

New Issue
Closed
opened 2026-04-20 00:42:29 -05:00 by GiteaMirror · 1 comment
GiteaMirror commented 2026-04-20 00:42:29 -05:00
Owner
Copy Link
Copy Source

Originally created by @alexandrsuk on GitHub (Oct 3, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/18030

Check Existing Issues

  • I have searched for any existing and/or related issues.
  • I have searched for any existing and/or related discussions.
  • I am using the latest version of Open WebUI.

Installation Method

Docker

Open WebUI Version

v0.6.32

Ollama Version (if applicable)

v0.12.3

Operating System

Windows 11 with Docker Desktop (WSL2 backend)

Browser (if applicable)

Chrome (Latest), Edge (Latest)

Confirmation

  • I have read and followed all instructions in README.md.
  • I am using the latest version of both Open WebUI and Ollama.
  • I have included the browser console logs.
  • I have included the Docker container logs.
  • I have provided every relevant configuration, setting, and environment variable used in my setup.
  • I have clearly listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc).
  • I have documented step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation. My steps:
  • Start with the initial platform/version/OS and dependencies used,
  • Specify exact install/launch/configure commands,
  • List URLs visited, user input (incl. example values/emails/passwords if needed),
  • Describe all options and toggles enabled or changed,
  • Include any files or environmental changes,
  • Identify the expected and actual result at each stage,
  • Ensure any reasonably skilled user can follow and hit the same issue.

Expected Behavior

When Web Search is configured to use a local SearXNG instance (proxied via Caddy with a self-signed certificate), the tool call should succeed. The Open WebUI backend should successfully connect to the https://caddy endpoint, retrieve search results from SearXNG, use the crawl4ai-server to scrape a resulting URL, and pass the content to the LLM.

Actual Behavior

The Web Search tool fails silently. The UI shows a generic "An error occurred while searching the web". The detailed tool output ("Zobrazit výsledek z web.run") shows an empty string "" as the result of the tool call.

This failure occurs despite the fact that a manual curl test from inside the same open-webui container to the exact same endpoints (https://caddy and http://searxng:8080) is 100% successful, returning a valid JSON payload. This proves the network, DNS, and server configurations are all correct.

Steps to Reproduce

  1. Setup the environment with the following files:

    • docker-compose.yml:

      services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    ports:
      - "8080:8080"
    environment:
      - 'OLLAMA_BASE_URL=http://ollama:11434' # Replace with a running Ollama instance
      - ENABLE_RAG_WEB_SEARCH=true
      - RAG_WEB_SEARCH_ENGINE=searxng
      - RAG_SEARXNG_API_URL=https://caddy/
      - WEBUI_REQUEST_SSL_VERIFY=false
      - HTTP_PROXY=
      - HTTPS_PROXY=
      - NO_PROXY=localhost,127.0.0.1,caddy,searxng
    networks:
      - webui-net

  searxng:
    container_name: searxng
    image: searxng/searxng:latest
    environment:
      - SEARXNG_BASE_URL=https://localhost
      - SEARXNG_SECRET_KEY=my-super-secret-key
    networks:
      - webui-net

  caddy:
    container_name: caddy
    image: caddy:2-alpine
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
    networks:
      - webui-net

networks:
  webui-net:

    • Caddyfile:

      https://caddy {
    tls internal
    reverse_proxy searxng:8080
}

  2. Launch the stack:

    docker-compose up -d

  3. Configure Open WebUI:

    • Go to http://localhost:8080. Create an admin account.
    • Go to Admin Settings -> Web Search.
    • Set the "Query URL for Searxng" to: https://caddy/search?q=<query>&format=json
    • Enable Web Search for a model.

  4. Test:

    • Start a new chat.
    • Ask a question that requires web search, e.g., "What is the capital of Czechia?".

  5. Observe:

    • Expected Result: The AI should use the tool and answer "Prague".
    • Actual Result: The UI returns "An error occurred while searching the web". The tool detail shows an empty string "".

Logs & Screenshots

The problem is best demonstrated by the following test. The application fails, but a manual curl test from inside the exact same container succeeds perfectly. This proves the issue is with the application's HTTP client, not the environment.

1. Open WebUI Tool Log (The Failure)
This is what the tool returns in the UI:

{
  "query": "some search query",
  "source": "news",
  "topn": 10
}
""

2. SUCCESSFUL curl Test from inside the open-webui container (The Proof)
This test proves the network path is fully functional.

# Command run inside the container:
# docker-compose exec open-webui /bin/bash
# curl -v -k "https://caddy/search?q=test&format=json"

# Result: SUCCESS
* Trying 172.19.0.4:443...
* Connected to caddy (172.19.0.4) port 443 (#0)
* ALPN: offers h2,http/1.1
* ... (TLS handshake details) ...
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
* SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
* ...
< HTTP/2 200
< content-type: application/json
< content-length: 23527
<
{"query": "test", "number_of_results": 0, "results": [...]}
* Connection #0 to host caddy left intact

Additional Information

After deep investigation, the root cause was found in the source code.

The web search functionality for SearXNG is handled by the file backend/open_webui/retrieval/web/searxng.py.

In this file, the HTTP request is made using the requests library:
https://github.com/open-webui/open-webui/blob/main/backend/open_webui/retrieval/web/searxng.py#L90-L101

response = requests.get(
    query_url,
    headers={...},
    params=params,
)

This call is missing the verify parameter. Because of this, the requests client does not respect the WEBUI_REQUEST_SSL_VERIFY=false environment variable.

When connecting to a local SearXNG instance proxied via Caddy (which uses a self-signed certificate for internal HTTPS), the SSL verification fails, but the exception seems to be handled improperly, resulting in a silent failure (empty string response).

Suggested Fix:
The requests.get call should be updated to respect the WEBUI_REQUEST_SSL_VERIFY environment variable, similar to this:

import os
# ...
verify_ssl = os.getenv("WEBUI_REQUEST_SSL_VERIFY", "true").lower() == "true"
# ...
response = requests.get(
    query_url,
    headers={...},
    params=params,
    verify=verify_ssl  # <-- ADD THIS LINE
)

Thank you for your great work on this project!
Originally created by @alexandrsuk on GitHub (Oct 3, 2025). Original GitHub issue: https://github.com/open-webui/open-webui/issues/18030 ### Check Existing Issues - [x] I have searched for any existing and/or related issues. - [x] I have searched for any existing and/or related discussions. - [x] I am using the latest version of Open WebUI. ### Installation Method Docker ### Open WebUI Version v0.6.32 ### Ollama Version (if applicable) v0.12.3 ### Operating System Windows 11 with Docker Desktop (WSL2 backend) ### Browser (if applicable) Chrome (Latest), Edge (Latest) ### Confirmation - [x] I have read and followed all instructions in `README.md`. - [x] I am using the latest version of **both** Open WebUI and Ollama. - [x] I have included the browser console logs. - [x] I have included the Docker container logs. - [x] I have **provided every relevant configuration, setting, and environment variable used in my setup.** - [x] I have clearly **listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup** (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc). - [x] I have documented **step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation**. My steps: - Start with the initial platform/version/OS and dependencies used, - Specify exact install/launch/configure commands, - List URLs visited, user input (incl. example values/emails/passwords if needed), - Describe all options and toggles enabled or changed, - Include any files or environmental changes, - Identify the expected and actual result at each stage, - Ensure any reasonably skilled user can follow and hit the same issue. ### Expected Behavior When Web Search is configured to use a local SearXNG instance (proxied via Caddy with a self-signed certificate), the tool call should succeed. The Open WebUI backend should successfully connect to the `https://caddy` endpoint, retrieve search results from SearXNG, use the `crawl4ai-server` to scrape a resulting URL, and pass the content to the LLM. ### Actual Behavior The Web Search tool fails silently. The UI shows a generic "An error occurred while searching the web". The detailed tool output ("Zobrazit výsledek z web.run") shows an empty string `""` as the result of the tool call. This failure occurs despite the fact that a manual `curl` test from *inside the same `open-webui` container* to the exact same endpoints (`https://caddy` and `http://searxng:8080`) is **100% successful**, returning a valid JSON payload. This proves the network, DNS, and server configurations are all correct. ### Steps to Reproduce 1. **Setup the environment** with the following files: * `docker-compose.yml`: ```yaml services: open-webui: image: ghcr.io/open-webui/open-webui:main container_name: open-webui ports: - "8080:8080" environment: - 'OLLAMA_BASE_URL=http://ollama:11434' # Replace with a running Ollama instance - ENABLE_RAG_WEB_SEARCH=true - RAG_WEB_SEARCH_ENGINE=searxng - RAG_SEARXNG_API_URL=https://caddy/ - WEBUI_REQUEST_SSL_VERIFY=false - HTTP_PROXY= - HTTPS_PROXY= - NO_PROXY=localhost,127.0.0.1,caddy,searxng networks: - webui-net searxng: container_name: searxng image: searxng/searxng:latest environment: - SEARXNG_BASE_URL=https://localhost - SEARXNG_SECRET_KEY=my-super-secret-key networks: - webui-net caddy: container_name: caddy image: caddy:2-alpine volumes: - ./Caddyfile:/etc/caddy/Caddyfile:ro networks: - webui-net networks: webui-net: ``` * `Caddyfile`: ```caddy https://caddy { tls internal reverse_proxy searxng:8080 } ``` 2. **Launch the stack:** ```bash docker-compose up -d ``` 3. **Configure Open WebUI:** * Go to `http://localhost:8080`. Create an admin account. * Go to Admin Settings -> Web Search. * Set the "Query URL for Searxng" to: `https://caddy/search?q=<query>&format=json` * Enable Web Search for a model. 4. **Test:** * Start a new chat. * Ask a question that requires web search, e.g., "What is the capital of Czechia?". 5. **Observe:** * **Expected Result:** The AI should use the tool and answer "Prague". * **Actual Result:** The UI returns "An error occurred while searching the web". The tool detail shows an empty string `""`. ### Logs & Screenshots The problem is best demonstrated by the following test. The application fails, but a manual `curl` test from inside the exact same container succeeds perfectly. This proves the issue is with the application's HTTP client, not the environment. **1. Open WebUI Tool Log (The Failure)** This is what the tool returns in the UI: ```json { "query": "some search query", "source": "news", "topn": 10 } "" ``` **2. SUCCESSFUL `curl` Test from inside the `open-webui` container (The Proof)** This test proves the network path is fully functional. ```bash # Command run inside the container: # docker-compose exec open-webui /bin/bash # curl -v -k "https://caddy/search?q=test&format=json" # Result: SUCCESS * Trying 172.19.0.4:443... * Connected to caddy (172.19.0.4) port 443 (#0) * ALPN: offers h2,http/1.1 * ... (TLS handshake details) ... * SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256 * SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway. * ... < HTTP/2 200 < content-type: application/json < content-length: 23527 < {"query": "test", "number_of_results": 0, "results": [...]} * Connection #0 to host caddy left intact ``` ### Additional Information After deep investigation, the root cause was found in the source code. The web search functionality for SearXNG is handled by the file `backend/open_webui/retrieval/web/searxng.py`. In this file, the HTTP request is made using the `requests` library: https://github.com/open-webui/open-webui/blob/main/backend/open_webui/retrieval/web/searxng.py#L90-L101 ```python response = requests.get( query_url, headers={...}, params=params, ) This call is missing the verify parameter. Because of this, the requests client does not respect the WEBUI_REQUEST_SSL_VERIFY=false environment variable. When connecting to a local SearXNG instance proxied via Caddy (which uses a self-signed certificate for internal HTTPS), the SSL verification fails, but the exception seems to be handled improperly, resulting in a silent failure (empty string response). Suggested Fix: The requests.get call should be updated to respect the WEBUI_REQUEST_SSL_VERIFY environment variable, similar to this: import os # ... verify_ssl = os.getenv("WEBUI_REQUEST_SSL_VERIFY", "true").lower() == "true" # ... response = requests.get( query_url, headers={...}, params=params, verify=verify_ssl # <-- ADD THIS LINE ) Thank you for your great work on this project!
GiteaMirror added the bug label 2026-04-20 00:42:29 -05:00
GiteaMirror commented 2026-04-20 00:42:31 -05:00
Author
Owner
Copy Link
Copy Source

@PurpleBanana-ai commented on GitHub (Oct 5, 2025):

This is my first time commenting on here so forgive me if I am not in alignment with the policies. I just wanted to put out there that I am experiencing the same issue outside of docker. I noticed in the contrib guide, docker configs were called out specifically. I am running the same version of open-webui as above v.0.6.32, but I am running on Ubuntu 24 in a conda venv and using uvx to lauch. My SearXNG instance is in a venv as well, just on a different machine in my local network.

I can perform a curl command from within my open-webui venv using https and get results, however in my open-webui interface I have to use http in order for the chat to provide results. When I pull a query on the postgresql config table, I can see the "ssl_verification" variable = true. I have also verified the ssl cert is in the project directory, and can access the search instance from any other device or browser without error.

If there is any other information I can provide to help just let me know, or if this is not correctly posted, I apologize.

Thank you for providing such a great system.

<!-- gh-comment-id:3368738918 --> @PurpleBanana-ai commented on GitHub (Oct 5, 2025): This is my first time commenting on here so forgive me if I am not in alignment with the policies. I just wanted to put out there that I am experiencing the same issue outside of docker. I noticed in the contrib guide, docker configs were called out specifically. I am running the same version of open-webui as above v.0.6.32, but I am running on Ubuntu 24 in a conda venv and using uvx to lauch. My SearXNG instance is in a venv as well, just on a different machine in my local network. I can perform a curl command from within my open-webui venv using https and get results, however in my open-webui interface I have to use http in order for the chat to provide results. When I pull a query on the postgresql config table, I can see the "ssl_verification" variable = true. I have also verified the ssl cert is in the project directory, and can access the search instance from any other device or browser without error. If there is any other information I can provide to help just let me know, or if this is not correctly posted, I apologize. Thank you for providing such a great system.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
confirmed
confirmed issue
core
documentation
enhancement
good first issue
help wanted
non-core
pull-request
Mirrored from GitHub Pull Request
 python
question
testing wanted
No labels bug
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
GiteaMirror ninjasurge (Kaehlen Rog)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/open-webui#18469