I have tried and tried to go to administrative settings and then use web search to get current answers to questions and get an error, and it defaults back to answers from the model creation. I have put in a google api key, search engine id, and set my search to google. ( I think I did all this correctly) I don’t know what I’m lacking or what I’m doing wrong??? I have watched every YouTube video out there. Help!!
There seems to be a failure mode specific to OpenWebUI + Gemma 3 1B.
You are probably not missing one tiny checkbox. The more likely explanation is that OpenWebUI web search is failing in the middle of its pipeline, and Gemma 3 1B makes that much more likely. OpenWebUI’s current docs split web search into multiple layers: provider setup, query generation or tool use, model capability flags, content fetching, and final answer generation. They also say small local models often struggle with Native mode tool use, while Google’s own Gemma docs recommend Gemma 3 12B or 27B for function-calling performance, not 1B. (Open WebUI)
What is probably happening in your case
When OpenWebUI cannot complete the search path cleanly, it often falls back to answering from the model’s built-in knowledge. That matches what you described. There are multiple similar OpenWebUI reports with symptoms like “No search query generated”, query-generation failures, or Google PSE errors that end with stale or generic answers instead of live results. (GitHub)
For Gemma 3 1B specifically, there are two different failure modes depending on how you configured OpenWebUI:
1. If you are using Default mode
OpenWebUI says the TASK_MODEL is used for tasks such as web search query generation. By default, that often ends up being the same model you are chatting with unless you explicitly set something stronger. So if you are chatting with Gemma 3 1B, OpenWebUI may also be asking that 1B model to generate the search query that drives the whole web search flow. That is a weak point. (Open WebUI)
2. If you are using Native mode
OpenWebUI injects search_web and fetch_url tools into the model, but its own docs warn that small local models under 30B often struggle with Native mode. The stated failure modes include malformed tool output, poor tool choices, and unreliable multi-step behavior. OpenWebUI explicitly says Default mode is usually more reliable for small local models. (Open WebUI)
That is why your setup can look correct in the admin panel and still behave like “search does not work.”
Why Google PSE may also be part of the problem
Your Google setup may still be wrong even if it looks right.
Google’s official docs say the Custom Search JSON API requires:
- a configured Programmable Search Engine
- an API key
- the engine ID
cx, which is found in the engine’s Basic section. (Google for Developers)
Google also says:
- the API is closed to new customers
- existing customers have until January 1, 2027 to transition
- there are 100 free queries/day before paid usage. (Google for Developers)
So Google PSE is still usable for eligible existing customers, but in 2026 it is not the most forgiving or future-proof provider.
There are also direct OpenWebUI bug reports showing Google PSE returning 400 INVALID_ARGUMENT from the Google endpoint even when users thought they had configured it correctly. That is a real, documented failure pattern. (GitHub)
A common Google-specific mistake
The API key may be restricted for the wrong kind of client.
Google’s API key docs say restrictions can be set by:
- HTTP referrer for browser keys
- server IP for backend/server keys. (Google Cloud Documentation)
OpenWebUI calls Google PSE from the backend, not from your browser tab. So a key restricted like a browser key can fail when OpenWebUI uses it server-side. That is one of the first Google-side things I would suspect.
Another common mistake: the engine itself is not set up the way you expect
Google’s help docs say:
- you can still use a Programmable Search Engine configured to search the entire web
- but no new creation is supported
- and even then, results can differ from normal Google Search because PSE emphasizes your configured sites and may use only a subset of Google Web Search results. (Google Help)
So even a “working” Google PSE setup does not behave exactly like google.com.
Also, Google’s help says the “Search the entire web” setting is managed in the control panel under the engine’s settings, and once toggled off on an existing engine it cannot be toggled back on. (Google Help)
OpenWebUI setting traps that matter a lot
In current OpenWebUI builds, Native mode requires more than just “Web Search enabled.”
The docs say that in Native mode you need:
- global web search configured
- the model’s Web Search capability enabled
- Web Search enabled under the model’s Default Features or toggled on in the chat
- Native function calling enabled for that model. (Open WebUI)
If any of that is missing, the search_web and fetch_url tools are not injected, and the model answers from its own weights instead. (Open WebUI)
There is also a recent OpenWebUI issue reporting that web search behavior breaks depending on the interaction between Web Search and Builtin Tools. In that report, search worked only when Builtin Tools was enabled, and failed when Builtin Tools was off even if Web Search was on. (GitHub)
So yes, the current settings model is confusing enough that you can do a lot “right” and still not actually have working search.
One more hidden problem: PersistentConfig
OpenWebUI marks many of these settings as PersistentConfig, including:
TASK_MODELGOOGLE_PSE_API_KEYGOOGLE_PSE_ENGINE_ID- web-search-related settings. (Open WebUI)
That means if you changed values in the UI before, the database-stored values can override what you later put in .env or Docker env vars. So restarting the container does not always mean your latest env values are the ones actually being used. (Open WebUI)
Another reason it can look broken even when search technically runs
OpenWebUI’s troubleshooting docs say web search can fail after the provider returns results. Common reasons are:
- proxy-related fetch failures unless Trust Proxy Environment is enabled
- empty fetched content
- too-small context window
- poor loader choice. (Open WebUI)
The docs specifically recommend increasing context length to 16384+ for web content because pages often contain 4,000–8,000+ tokens. Gemma 3 1B only has a 32K context window, while larger Gemma 3 sizes have 128K. (Open WebUI)
So even if search partly works, a 1B model can still end up acting stale because it does not use the fetched material well.
What I think is most likely, in order
Most likely
Gemma 3 1B is the wrong model for this job.
If you are in Default mode, it is probably weak at query generation. If you are in Native mode, it is probably weak at tool use. Both are documented risk areas. (Open WebUI)
Second most likely
You enabled web search globally but not fully at the model/chat level.
That includes Native mode, Web Search capability, Default Features, chat toggle, and possibly Builtin Tools interactions. (Open WebUI)
Third most likely
Your Google PSE config is incomplete or rejected server-side.
That could be the wrong cx, a browser-restricted API key, the wrong engine type, or the documented Google PSE INVALID_ARGUMENT issue seen in OpenWebUI. (Google for Developers)
Fourth
Search returns something, but fetching/extraction/context makes the final answer useless.
That usually shows up as stale or generic responses even though “search” seems to happen. (Open WebUI)
What to check first
Do these in this order.
1. Stop testing with Gemma 3 1B as the search brain
For diagnosis, switch to:
- Default mode first, not Native mode
- and a stronger model for search-related tasks if possible. OpenWebUI and Google’s own Gemma docs both point away from 1B for tool-heavy workflows. (Open WebUI)
2. Verify Google PSE outside OpenWebUI
Test the Google API directly. Google’s REST docs say each request needs key, cx, and q. (Google for Developers)
curl "https://www.googleapis.com/customsearch/v1?key=YOUR_API_KEY&cx=YOUR_ENGINE_ID&q=latest+OpenWebUI"
Interpretation:
- JSON with
items→ Google side basically works - 400/403 → Google side is wrong or restricted
- no useful results → engine setup may be wrong or not configured how you think. (Google for Developers)
3. Confirm your cx
Google’s official help says the Search Engine ID is in the engine’s Basic section. (Google Help)
4. Confirm whether the engine is really set to search the web
Google’s help says PSE can search the whole web, but it behaves differently from Google Search and can still emphasize your sites or use only a subset of the corpus. (Google Help)
5. Check the API key restriction type
If the key is restricted, it likely needs to be valid for server/backend use, not only browser referrers. (Google Cloud Documentation)
6. Re-check the OpenWebUI model settings
For your model, verify:
- Web Search capability
- Web Search in Default Features
- Function Calling mode
- chat-level Web Search toggle
- Builtin Tools behavior if you are in Native mode. (Open WebUI)
7. Check logs
OpenWebUI’s troubleshooting page says to check logs, and recent issues show the exact kinds of messages to look for:
No search query generatedNoneTypeerrors during search generation- Google
INVALID_ARGUMENT - timeout or empty-content fetch errors. (Open WebUI)
8. If search succeeds but answers stay stale
Check:
- context length set to 16384+
- proxy trust
- loader engine. (Open WebUI)
The blunt conclusion
Your setup is probably failing because Gemma 3 1B is too weak for OpenWebUI’s search orchestration path, and Google PSE is a brittle provider choice with several configuration traps. The result is exactly what you described: an error appears, then the model falls back to old built-in knowledge instead of giving a current answer. (Open WebUI)
The fastest way out is usually:
- test Google directly with
curl - switch OpenWebUI to Default mode
- stop using Gemma 3 1B for query/tool orchestration
- then verify model capability and chat toggles. (Google for Developers)
OMG… thank you for this indepth answer. The PC I am using is not capable of much more than that size of a model. I am a youtube certified old man, wishing for younger days. I am envious of all these younger people. My finances also dictate (for the near future) expanding to a better set up. I will eventually. I am learning sooooo much.
I see. I’m an old guy too.
When it comes to small models around 1B, besides Gemma 3, the Liquid LFM and Qwen 3/3.5 are also excellent options. The Liquid models seem to have a particularly good reputation because they’re fine-tuned specifically for edge devices.
https://huggingface.co/LiquidAI/LFM2.5-1.2B-Instruct
https://huggingface.co/collections/LiquidAI/lfm25
Hi @John6666 ,
Could it be that the behavior described also applies to the Mistral3-3b model—that it might also be too small?
Searchengine:
Selfhost SearXNG on an other device.
Port 8080; format:json, html; synthax: http://192.168.xxx.x:8080/search?q=
I’ve really tried every possible search configuration—but the error message persists…
Hmm… This does look similar on the surface, but I suspect this may be a different failure mode
:
Short answer
I would not diagnose this as “Mistral 3 3B is definitely too small” yet.
A 3B model can still be a contributing factor, especially in Open WebUI’s Native / Agentic tool-calling mode, but your SearXNG details point to a more basic layer first:
- the SearXNG query URL shape,
- whether JSON output is actually enabled in SearXNG,
- whether the Open WebUI container can reach your SearXNG instance,
- whether Open WebUI is sending an empty
q=query, - and whether Web Search / Native tool injection is enabled for that model/chat.
So my first guess would be:
Mistral 3 3B may be part of the problem, but I would first verify the SearXNG integration path and the actual backend log. This may be closer to a SearXNG / empty-query / connectivity issue than a pure model-size issue.
Why I would check SearXNG before blaming the model
The detail that stands out is this URL shape:
http://192.168.xxx.x:8080/search?q=
Open WebUI’s SearXNG documentation shows the query URL in this shape:
http://searxng:8080/search?q=<query>
Reference:
So I would first verify whether your actual configured URL is really:
http://192.168.xxx.x:8080/search?q=<query>
rather than only:
http://192.168.xxx.x:8080/search?q=
I would not say this is definitely the bug, because Open WebUI versions and UI paths may handle query parameters differently. But it is one of the first things I would verify.
There is also an older Open WebUI issue specifically about confusion around the correct SearXNG query URL:
The most useful distinction: what does the actual error say?
Different logs point to different layers.
| Actual symptom / log | First thing I would suspect | Why |
|---|---|---|
403 Client Error: Forbidden |
SearXNG JSON output is not enabled | SearXNG often disables non-HTML formats unless configured |
400 BAD REQUEST with q= empty |
Open WebUI is sending an empty query, or query generation failed | There are existing Open WebUI reports with exactly this pattern |
| Browser test works, Open WebUI fails | Docker / LAN / container networking | The browser and the Open WebUI container may not see the same network |
| Search starts but answer ignores results | Tool chain / fetch_url / context usage issue |
Search and page fetching are separate steps in Agentic mode |
No search query generated |
Model did not produce the expected query format, or Open WebUI’s query generation step failed | This can depend on the model and its instruction-following ability |
| Tool call JSON is malformed | Model/tool-calling weakness | Small local models can struggle with strict tool-call formatting |
Step 1: test SearXNG JSON directly from inside the Open WebUI container
Testing SearXNG from your browser is useful, but it is not enough.
The decisive test is whether the Open WebUI container can reach SearXNG and receive JSON.
Try something like this, changing the container name if needed:
docker exec -it open-webui curl \
"http://192.168.xxx.x:8080/search?q=test&format=json"
If this fails, then the model is not the first problem yet.
Possible outcomes:
| Result | Meaning |
|---|---|
| JSON response with search results | SearXNG is reachable from Open WebUI |
403 Forbidden |
JSON format is probably not enabled in SearXNG |
400 BAD REQUEST |
Check whether the query is empty or malformed |
| connection refused / timeout | Docker, LAN, firewall, host binding, or wrong address |
| HTML instead of JSON | SearXNG is not returning JSON for that request |
Relevant docs:
Step 2: if you see 403, check SearXNG json format
SearXNG needs JSON output enabled. In settings.yml, it should look like this:
search:
formats:
- html
- json
Then restart SearXNG.
Open WebUI’s troubleshooting guide calls out this exact case:
SearXNG’s own API docs also say that supported output formats are defined in settings.yml, and requesting an unset format returns 403 Forbidden:
Related reports:
- Open WebUI issue #2824 — 403 Error with websearch using SearXNG engine
- Stack Overflow — Error while enabling SearXNG as web search engine in Open WebUI
Step 3: if you see empty q=, that is a different issue
There are Open WebUI reports where SearXNG is called with an empty query, for example:
/search?q=&format=json
That is a different failure mode from “SearXNG is not running”.
Useful references:
- Open WebUI discussion #11125 — Web search fails with SearXNG integration: Empty q parameter causes 400 BAD REQUEST
- Open WebUI issue #9995 — web search using searxng: No search query generated
- Open WebUI discussion #10027 — web search using searxng: No search query generated
- Open WebUI discussion #7096 — Version 0.4.1 never searches web
In one of those discussions, a contributor explains that No search query generated can happen when the model’s response is not formatted as Open WebUI expects for web search query generation.
That means this kind of failure can sit between two layers:
- SearXNG may be reachable.
- But Open WebUI may not be generating or passing a valid query to it.
So if your backend log shows an empty q=, I would not focus on SearXNG JSON first. I would look at query generation, Web Search settings, model settings, and Native/Default mode behavior.
Step 4: verify Open WebUI Web Search / Native settings
Open WebUI’s current docs describe Web Search in Native / Agentic mode as a tool-based pipeline.
The important part is that search_web and fetch_url are not always injected automatically. According to the docs, Native mode requires the relevant Web Search capability/settings to be enabled.
Relevant docs:
- Open WebUI — Agentic Web Search & URL Fetching
- Open WebUI — Tools / Native Mode
- Open WebUI — Web Search troubleshooting
Things I would check:
| Setting area | What to verify |
|---|---|
| Admin Web Search settings | Web Search is globally enabled |
| Search provider | SearXNG is selected |
| SearXNG query URL | The URL uses the expected <query> placeholder if required |
| Model settings | Web Search capability/default feature is enabled for this model |
| Chat UI | Web Search is toggled on for the chat if not enabled by default |
| Function calling mode | Native mode is enabled if you are testing Agentic search |
| Backend logs | Confirm whether search_web is actually called |
Step 5: yes, model size can still matter
This is where Mistral 3 3B comes back into the picture.
Mistral / Ministral 3 3B may support function calling or JSON-style outputs at the model-family level, but that does not guarantee perfect behavior inside every Open WebUI Native/Agentic workflow.
References:
Open WebUI’s Tools docs explicitly warn that smaller local models may technically support function calling but still struggle with:
- malformed JSON,
- strict tool-call formatting,
- multi-step tool usage,
- state management,
- deciding when to call which tool.
So I would phrase the model-size diagnosis carefully:
Mistral 3 3B may be too weak or inconsistent for reliable Native/Agentic web search in some setups, but I would not treat that as proven until the SearXNG URL, JSON response, container connectivity, and actual
q=value are checked.
A simple A/B test is useful here:
| Test | What it tells you |
|---|---|
| Same SearXNG setup + stronger known-good tool-calling model works | Mistral 3 3B is likely part of the problem |
| Same SearXNG setup fails with every model | SearXNG / Open WebUI configuration is more likely |
| SearXNG direct curl fails | Model is not the main issue yet |
Direct curl works, but Open WebUI sends q= empty |
Query generation / WebUI tool path is likely involved |
| Search works but pages are not read | fetch_url / agentic follow-up behavior may be involved |
Step 6: search vs fetch are separate in Agentic mode
One subtle point: in Open WebUI’s Agentic Web Search docs, search_web and fetch_url are separate tools.
Search can return titles, links, and snippets. Reading a page may require a separate URL-fetching step.
Relevant docs:
- Open WebUI — Agentic Web Search & URL Fetching
- Open WebUI discussion #21254 — Agentic Native Mode never uses fetch_url
So if your symptom is:
“It searches but does not really use the web result”
that may be different from:
“It never sends a search request”
and also different from:
“SearXNG returns 403 or 400”
Those should be debugged separately.
Step 7: another-device SearXNG means networking matters
Since your SearXNG is on another device, I would also check the network path from the Open WebUI runtime, not only from your laptop browser.
Common traps:
| Trap | Example |
|---|---|
localhost confusion |
localhost inside Docker is the container, not the host or another device |
| LAN firewall | Browser from one machine works, container from another does not |
| SearXNG only bound to loopback | SearXNG listens on 127.0.0.1, not LAN |
| wrong port exposure | SearXNG UI works locally but not across LAN |
| reverse proxy mismatch | Browser URL differs from backend URL |
| Docker network DNS | searxng hostname only works if containers share the same Docker network |
A related Open WebUI report where web search was not working and connection behavior varied:
For a separate-device setup, I would prefer testing with the real LAN IP:
docker exec -it open-webui curl \
"http://192.168.xxx.x:8080/search?q=test&format=json"
If Open WebUI and SearXNG are in the same Docker Compose stack, then the service name may be better:
http://searxng:8080/search?q=<query>
But if SearXNG is on another physical device, the service name searxng probably will not resolve unless you created that network/DNS path yourself.
Lower-probability but still relevant SearXNG details
If direct JSON requests work sometimes but return empty or inconsistent results, there are additional SearXNG-side possibilities.
One report mentions SearXNG limiter / pass_ip and checking SearXNG logs:
A practical SearXNG checklist:
| Item | Why it matters |
|---|---|
| JSON enabled | Needed for Open WebUI integration |
| SearXNG restarted after editing settings | Config changes may not apply until restart |
Correct settings.yml file |
Editing the wrong mounted file is common |
| SearXNG logs | Shows engine failures, limiter issues, bad requests |
| Engine selection | Some engines may fail or return empty results |
| Rate limiting / limiter config | Local integrations can still trigger limiter behavior |
| Browser vs curl difference | Browser cookies/preferences may hide curl/backend behavior |
I would not lead with these unless the basic curl ...format=json test gives strange or empty results.
Suggested debug order
I would debug in this order:
1. Check the exact Open WebUI backend log
Look for the actual URL Open WebUI sends.
Important details:
q=
q=test
format=json
403
400
No search query generated
Connection refused
No search results found
2. Test SearXNG from inside Open WebUI
docker exec -it open-webui curl \
"http://192.168.xxx.x:8080/search?q=test&format=json"
3. If 403, fix SearXNG JSON
search:
formats:
- html
- json
Restart SearXNG after editing.
4. If 400 with empty query, inspect Open WebUI query generation
Relevant issues:
5. Verify the SearXNG query URL
Expected style:
http://192.168.xxx.x:8080/search?q=<query>
or, in a same-Docker-network setup:
http://searxng:8080/search?q=<query>
6. Verify Web Search / Native mode settings
Use the current docs as the reference:
7. A/B test with a stronger tool-calling model
Only after the above checks pass, compare Mistral 3 3B with a stronger model.
If the stronger model works and Mistral 3 3B does not, then the model-size/tool-calling hypothesis becomes much stronger.
What information would make the diagnosis much easier?
If you can paste only a few things, I would ask for these:
1. Open WebUI version
2. Docker / pip / other deployment method
3. The exact SearXNG Query URL configured in Open WebUI
4. The actual backend log line when Web Search runs
5. Whether this command works from inside the Open WebUI container:
docker exec -it open-webui curl "http://192.168.xxx.x:8080/search?q=test&format=json"
6. Whether the error is 403, 400, empty q=, "No search query generated", or "No search results found"
7. Whether Web Search works with a stronger model in the same setup
That would separate these cases pretty quickly.
My current best guess
Based only on the information here, I would rank the likely causes like this:
| Rank | Candidate cause | Confidence | Why |
|---|---|---|---|
| 1 | SearXNG query URL / placeholder issue | Medium | The posted URL ends with q= rather than clearly showing q=<query> |
| 2 | Open WebUI sends empty q= / query generation fails |
Medium | Existing Open WebUI reports show this exact pattern |
| 3 | Open WebUI container cannot reach the other-device SearXNG | Medium | SearXNG is on another device, so browser tests are not enough |
| 4 | SearXNG JSON not actually enabled / not restarted / wrong config file | Medium | Very common, especially if logs show 403 |
| 5 | Mistral 3 3B is unreliable for Native/Agentic tool calling | Medium-low until the above pass | Plausible, but not the first thing to prove |
| 6 | SearXNG engine / limiter / preferences issue | Low-medium | Possible if direct JSON works inconsistently or returns empty results |
So the shortest version is:
I would not rule out Mistral 3 3B being too weak for reliable Native tool use, but your SearXNG setup has several earlier failure points. First verify that Open WebUI can reach SearXNG from inside its container, that
format=jsonworks, that the configured URL uses the expected query placeholder, and that the backend log is not sending an emptyq=. Only after those pass would I treat model size as the main suspect.