[GH-ISSUE #246] [BUG] Ollama: Cannot connect to host ollama.com:443 ssl:default [Could not contact DNS servers] #158

New issue

Open

opened 2026-10-18 14:06:34 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

2026-10-18 14:06:34 +00:00

Owner

Originally created by @Rafael-Silva-Oliveira on GitHub (Jul 27, 2026).
Original GitHub issue: https://github.com/open-webui/desktop/issues/246

Hello,

After installing the latest version of OpenWebUI (0.11) on the desktop app, I now get the error message above when trying to connect to https://ollama.com with my API key to use the cloud models. Nothing else in my connection changed, so I am wondering if this was some change made on OpenWebUI? Any fix for this?

I can use the Ollama cloud models through my localhost connection of Ollama which then redirects to the cloud models, but I can't seem to fetch the ollama cloud models using the API key.

Thanks! @tjbck

Originally created by @Rafael-Silva-Oliveira on GitHub (Jul 27, 2026). Original GitHub issue: https://github.com/open-webui/desktop/issues/246 Hello, After installing the latest version of OpenWebUI (0.11) on the desktop app, I now get the error message above when trying to connect to https://ollama.com with my API key to use the cloud models. Nothing else in my connection changed, so I am wondering if this was some change made on OpenWebUI? Any fix for this? I can use the Ollama cloud models through my localhost connection of Ollama which then redirects to the cloud models, but I can't seem to fetch the ollama cloud models using the API key. Thanks! @tjbck

bsakaguchi commented

2026-10-18 14:06:35 +00:00

Author

Owner

@Abrar-ashraf-817 commented on GitHub (Jul 28, 2026):

yeah this is a problem for like all cloud models, i tried openrouter, chutes, naga.ac, none of them work after open webui 0.11.0 got installed, only aiodns is not working for some reason? windows native dns lookup works so does python's native thread resolver, so idk, aiodns newer version does have breaking changes according to google, so probably that.

For me a very temporary fix that works for now is I went to the resolver,py file the error points to:
| ERROR | open_webui.routers.openai:generate_chat_completion:1427 - Cannot connect to host api.naga.ac:443 ssl:default [Could not contact DNS servers]
Traceback (most recent call last):
File "C:\Users<username>\AppData\Roaming\open-webui\python\Lib\site-packages\aiohttp\resolver.py", line 117, in resolve
resp = await self._resolver.getaddrinfo(
aiodns.error.DNSError: (11, 'Could not contact DNS servers')

and at the end of the file there's this line "DefaultResolver: _DefaultType = AsyncResolver if aiodns_default else ThreadedResolver",
I just changed it to DefaultResolver: _DefaultType = ThreadedResolver", works for now but it'll break if something updates.

@Abrar-ashraf-817 commented on GitHub (Jul 28, 2026): yeah this is a problem for like all cloud models, i tried openrouter, chutes, naga.ac, none of them work after open webui 0.11.0 got installed, only aiodns is not working for some reason? windows native dns lookup works so does python's native thread resolver, so idk, aiodns newer version does have breaking changes according to google, so probably that. For me a very temporary fix that works for now is I went to the resolver,py file the error points to: | ERROR | open_webui.routers.openai:generate_chat_completion:1427 - Cannot connect to host api.naga.ac:443 ssl:default [Could not contact DNS servers] Traceback (most recent call last): File "C:\Users\<username>\AppData\Roaming\open-webui\python\Lib\site-packages\aiohttp\resolver.py", line 117, in resolve resp = await self._resolver.getaddrinfo( aiodns.error.DNSError: (11, 'Could not contact DNS servers') and at the end of the file there's this line "DefaultResolver: _DefaultType = AsyncResolver if aiodns_default else ThreadedResolver", I just changed it to DefaultResolver: _DefaultType = ThreadedResolver", works for now but it'll break if something updates.

bsakaguchi commented

2026-10-18 14:06:35 +00:00

Author

Owner

@Rafael-Silva-Oliveira commented on GitHub (Aug 5, 2026):

Yep, it's not Ollama Cloud and it's not the API key, it's the DNS resolver that ships inside the desktop app's Python environment.

Short version: aiohttp picks AsyncResolver (c-ares, via aiodns/pycares) whenever aiodns can be imported, and only falls back to ThreadedResolver/getaddrinfo when it can't. The bundle ships aiodns, so c-ares is what's doing the lookups. c-ares doesn't ask Windows to resolve anything, it enumerates the network adapters and builds its own nameserver list. On my machine it built an empty list and fell back to its default of 127.0.0.1:53. Nothing is listening there, so Windows sends back an ICMP port unreachable, c-ares turns that into ARES_ECONNREFUSED, and the message for that error code happens to be "Could not contact DNS servers". So the backend was firing every DNS query at a dead port on my own machine.

You can see it in one line using the bundled interpreter:

& "$env:APPDATA\open-webui\python\python.exe" -c "import pycares; print(pycares.Channel().servers)"

Meanwhile the standard resolver in that same interpreter is working :

& "$env:APPDATA\open-webui\python\python.exe" -c "import socket; print(socket.gethostbyname('ollama.com'))"

The workaround, after quitting the app properly from the tray (simply renaming):

Rename-Item "$env:APPDATA\open-webui\python\Lib\site-packages\aiodns" "aiodns_disabled"

Relaunch and the connection works straight away. Renaming it back undoes it. Obviously an app update will put aiodns back and break it again.. Hope this will get fixed properly the next desktop release

@Rafael-Silva-Oliveira commented on GitHub (Aug 5, 2026): Yep, it's not Ollama Cloud and it's not the API key, it's the DNS resolver that ships inside the desktop app's Python environment. Short version: aiohttp picks `AsyncResolver` (c-ares, via `aiodns`/`pycares`) whenever `aiodns` can be imported, and only falls back to `ThreadedResolver`/`getaddrinfo` when it can't. The bundle ships aiodns, so c-ares is what's doing the lookups. c-ares doesn't ask Windows to resolve anything, it enumerates the network adapters and builds its own nameserver list. On my machine it built an empty list and fell back to its default of `127.0.0.1:53`. Nothing is listening there, so Windows sends back an ICMP port unreachable, c-ares turns that into `ARES_ECONNREFUSED`, and the message for that error code happens to be "Could not contact DNS servers". So the backend was firing every DNS query at a dead port on my own machine. You can see it in one line using the bundled interpreter: ```powershell & "$env:APPDATA\open-webui\python\python.exe" -c "import pycares; print(pycares.Channel().servers)" ``` Meanwhile the standard resolver in that same interpreter is working : ```powershell & "$env:APPDATA\open-webui\python\python.exe" -c "import socket; print(socket.gethostbyname('ollama.com'))" ``` The workaround, after quitting the app properly from the tray (simply renaming): ```powershell Rename-Item "$env:APPDATA\open-webui\python\Lib\site-packages\aiodns" "aiodns_disabled" ``` Relaunch and the connection works straight away. Renaming it back undoes it. Obviously an app update will put aiodns back and break it again.. Hope this will get fixed properly the next desktop release

bsakaguchi referenced this issue

2026-10-18 14:07:05 +00:00

[PR #160] [MERGED] 0.0.15 #220