github-starred/ollama
2
0
Fork 0
mirror of https://github.com/ollama/ollama.git synced 2026-11-10 15:02:13 -06:00
Code Issues 16.9k Packages Projects Releases 122 Wiki Activity

[GH-ISSUE #7023] In ollama/ollama:0.3.12 (latest) container, all external API requests using IPv6 work, but using IPv4 partially works #4453

New Issue
Closed
opened 2026-04-12 15:22:52 -05:00 by GiteaMirror · 16 comments
GiteaMirror commented 2026-04-12 15:22:52 -05:00
Owner
Copy Link
Copy Source

Originally created by @justincranford on GitHub (Sep 28, 2024).
Original GitHub issue: https://github.com/ollama/ollama/issues/7023

What is the issue?

Start the container:

docker run --rm -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama

Call / from Chrome on host
#. Localhost => GET http://localhost:11434/ => Works (i.e. "Ollama is running")
#. IPv6 => GET http://[::1]:11434/ => Works (i.e. "Ollama is running")
#. IPv4 => GET http://127.0.0.1:11434/ => Works (i.e. "Ollama is running")

Call /api/tags from Chrome on host
#. Localhost => GET http://localhost:11434/api/tags => Works
#. IPv6 => GET http://[::1]:11434/api/tags => Works
#. IPv4 => GET http://127.0.0.1:11434/api/tags => Works

Call /api/ps from Chrome on host
#. Localhost => GET http://localhost:11434/api/ps => Works
#. IPv6 => GET http://[::1]:11434/api/ps => Works
#. IPv4 => GET http://127.0.0.1:11434/api/ps => HTTP 404

The symptom reminds me of network split-brain, or dual HTTP server stacks with one misconfigured.

I am reporting this issue because I didn't find anything in docs to help, and search requests from Google or ChatGPT did not help.

The only hint I found was installing and running netstat. However, this still doesn't really explain why some IPv4 requests are getting through while others are not found.

apt update
apt upgrade
apt install net-tools
# netstat -an | grep LISTEN
tcp6       0      0 :::11434                :::*                    LISTEN

OS

Windows

GPU

AMD, Other

CPU

AMD

Ollama version

ollama version is 0.3.12

Originally created by @justincranford on GitHub (Sep 28, 2024). Original GitHub issue: https://github.com/ollama/ollama/issues/7023 ### What is the issue? Start the container: ``` docker run --rm -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama ``` Call / from Chrome on host #. Localhost => GET http://localhost:11434/ => Works (i.e. "Ollama is running") #. IPv6 => GET http://[::1]:11434/ => Works (i.e. "Ollama is running") #. IPv4 => GET http://127.0.0.1:11434/ => Works (i.e. "Ollama is running") Call /api/tags from Chrome on host #. Localhost => GET http://localhost:11434/api/tags => Works #. IPv6 => GET http://[::1]:11434/api/tags => Works #. IPv4 => GET http://127.0.0.1:11434/api/tags => Works Call /api/ps from Chrome on host #. Localhost => GET http://localhost:11434/api/ps => Works #. IPv6 => GET http://[::1]:11434/api/ps => Works #. IPv4 => GET http://127.0.0.1:11434/api/ps => **HTTP 404** The symptom reminds me of network split-brain, or dual HTTP server stacks with one misconfigured. I am reporting this issue because I didn't find anything in docs to help, and search requests from Google or ChatGPT did not help. The only hint I found was installing and running `netstat`. However, this still doesn't really explain why some IPv4 requests are getting through while others are not found. ``` apt update apt upgrade apt install net-tools # netstat -an | grep LISTEN tcp6 0 0 :::11434 :::* LISTEN ``` ### OS Windows ### GPU AMD, Other ### CPU AMD ### Ollama version ollama version is 0.3.12
GiteaMirror added the bug label 2026-04-12 15:22:52 -05:00
GiteaMirror commented 2026-04-12 15:22:53 -05:00
Author
Owner
Copy Link
Copy Source

@rick-github commented on GitHub (Sep 28, 2024):

What's in the body of the 404 response? Do you get the same error with a different client, eg curl http://127.0.0.1:11434/api/ps?

<!-- gh-comment-id:2381009862 --> @rick-github commented on GitHub (Sep 28, 2024): What's in the body of the 404 response? Do you get the same error with a different client, eg `curl http://127.0.0.1:11434/api/ps`?
GiteaMirror commented 2026-04-12 15:22:53 -05:00
Author
Owner
Copy Link
Copy Source

@justincranford commented on GitHub (Sep 29, 2024):

I tried localhost, [::1], and 127.0.0.1 three different ways.

  1. Inside ollama container => All 3 addresses work
  2. Power Shell on host system => Only localhost and [::1] work
  3. Chrome browser on host system => Only localhost and [::1] work

The 404 response body received on the host system is always 404 page not found.

Detailed results below:

Inside ollama container

docker run --rm -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama
docker exec -it ollama bash

apt update && apt upgrade -y && apt install -y curl
curl http://localhost:11434/api/ps
{"models":[]}
curl http://[::1]:11434/api/ps
{"models":[]}
curl http://127.0.0.1:11434/api/ps
{"models":[]}

In host system Power Shell

Run curl from Windows PowerShell using localhost.

 curl http://localhost:11434/api/ps

StatusCode        : 200
StatusDescription : OK
Content           : {"models":[]}
RawContent        : HTTP/1.1 200 OK
                    Content-Length: 13
                    Content-Type: application/json; charset=utf-8
                    Date: Sun, 29 Sep 2024 00:15:06 GMT

                    {"models":[]}
Forms             : {}
Headers           : {[Content-Length, 13], [Content-Type, application/json; charset=utf-8], [Date, Sun, 29 Sep 2024
                    00:15:06 GMT]}
Images            : {}
InputFields       : {}
Links             : {}
ParsedHtml        : System.__ComObject
RawContentLength  : 13

Run curl from Windows PowerShell using [::1].

curl http://[::1]:11434/api/ps

StatusCode        : 200
StatusDescription : OK
Content           : {"models":[]}
RawContent        : HTTP/1.1 200 OK
                    Content-Length: 13
                    Content-Type: application/json; charset=utf-8
                    Date: Sun, 29 Sep 2024 00:16:25 GMT

                    {"models":[]}
Forms             : {}
Headers           : {[Content-Length, 13], [Content-Type, application/json; charset=utf-8], [Date, Sun, 29 Sep 2024
                    00:16:25 GMT]}
Images            : {}
InputFields       : {}
Links             : {}
ParsedHtml        : System.__ComObject
RawContentLength  : 13

Run curl from Windows PowerShell using 127.0.0.1.

curl http://127.0.0.1:11434/api/ps

curl : 404 page not found
At line:1 char:1
+ curl http://127.0.0.1:11434/api/ps
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebExc
   eption
    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

Run HTTP GET from Chrome for 127.0.0.1 with Dev Tools enabled

image

image

<!-- gh-comment-id:2381036068 --> @justincranford commented on GitHub (Sep 29, 2024): I tried localhost, [::1], and 127.0.0.1 three different ways. 1. Inside ollama container => All 3 addresses work 2. Power Shell on host system => Only localhost and [::1] work 3. Chrome browser on host system => Only localhost and [::1] work The 404 response body received on the host system is always `404 page not found`. Detailed results below: ## Inside ollama container ``` docker run --rm -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama docker exec -it ollama bash apt update && apt upgrade -y && apt install -y curl curl http://localhost:11434/api/ps {"models":[]} curl http://[::1]:11434/api/ps {"models":[]} curl http://127.0.0.1:11434/api/ps {"models":[]} ``` ## In host system Power Shell Run curl from Windows PowerShell using localhost. ``` curl http://localhost:11434/api/ps StatusCode : 200 StatusDescription : OK Content : {"models":[]} RawContent : HTTP/1.1 200 OK Content-Length: 13 Content-Type: application/json; charset=utf-8 Date: Sun, 29 Sep 2024 00:15:06 GMT {"models":[]} Forms : {} Headers : {[Content-Length, 13], [Content-Type, application/json; charset=utf-8], [Date, Sun, 29 Sep 2024 00:15:06 GMT]} Images : {} InputFields : {} Links : {} ParsedHtml : System.__ComObject RawContentLength : 13 ``` Run curl from Windows PowerShell using [::1]. ``` curl http://[::1]:11434/api/ps StatusCode : 200 StatusDescription : OK Content : {"models":[]} RawContent : HTTP/1.1 200 OK Content-Length: 13 Content-Type: application/json; charset=utf-8 Date: Sun, 29 Sep 2024 00:16:25 GMT {"models":[]} Forms : {} Headers : {[Content-Length, 13], [Content-Type, application/json; charset=utf-8], [Date, Sun, 29 Sep 2024 00:16:25 GMT]} Images : {} InputFields : {} Links : {} ParsedHtml : System.__ComObject RawContentLength : 13 ``` Run curl from Windows PowerShell using 127.0.0.1. ``` curl http://127.0.0.1:11434/api/ps curl : 404 page not found At line:1 char:1 + curl http://127.0.0.1:11434/api/ps + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebExc eption + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand ``` ## Run HTTP GET from Chrome for 127.0.0.1 with Dev Tools enabled ![image](https://github.com/user-attachments/assets/ba639ea6-ac72-4551-8fe2-77aec594af5e) ![image](https://github.com/user-attachments/assets/fde595a4-6b2a-4b44-ba9f-e42c03b83a00)
GiteaMirror commented 2026-04-12 15:22:53 -05:00
Author
Owner
Copy Link
Copy Source

@rick-github commented on GitHub (Sep 29, 2024):

Strange behaviour. Can you install tcpflow in the container so we can see what the ollama server is receiving?

$ docker exec ollama bash -c 'apt update && apt install -y tcpflow'
$ docker exec ollama tcpflow -i any -c

and then run your tests.

<!-- gh-comment-id:2381041846 --> @rick-github commented on GitHub (Sep 29, 2024): Strange behaviour. Can you install tcpflow in the container so we can see what the ollama server is receiving? ```console $ docker exec ollama bash -c 'apt update && apt install -y tcpflow' $ docker exec ollama tcpflow -i any -c ``` and then run your tests.
GiteaMirror commented 2026-04-12 15:22:54 -05:00
Author
Owner
Copy Link
Copy Source

@justincranford commented on GitHub (Sep 29, 2024):

tcpflow results when host browser loads http://localhost:11434/api/ps

172.017.000.001.35586-172.017.000.002.11434: GET /api/ps HTTP/1.1
Host: localhost:11434
Connection: keep-alive
sec-ch-ua: "Google Chrome";v="129", "Not=A?Brand";v="8", "Chromium";v="129"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
DNT: 1
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/129.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Sec-Fetch-Site: cross-site
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Accept-Encoding: gzip, deflate, br, zstd
Accept-Language: en-US,en;q=0.9


172.017.000.002.11434-172.017.000.001.35586: HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Date: Sun, 29 Sep 2024 06:23:28 GMT
Content-Length: 13

{"models":[]}

tcpflow results when host browser loads http://[::1]:11434/api/ps

172.017.000.001.39736-172.017.000.002.11434: GET /api/ps HTTP/1.1
Host: [::1]:11434
Connection: keep-alive
sec-ch-ua: "Google Chrome";v="129", "Not=A?Brand";v="8", "Chromium";v="129"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
DNT: 1
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/129.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Sec-Fetch-Site: none
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Accept-Encoding: gzip, deflate, br, zstd
Accept-Language: en-US,en;q=0.9


172.017.000.002.11434-172.017.000.001.39736: HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Date: Sun, 29 Sep 2024 06:23:53 GMT
Content-Length: 13

{"models":[]}

tcpflow results when host browser loads http://127.0.0.1:11434/api/ps => Nothing is logged

<!-- gh-comment-id:2381127590 --> @justincranford commented on GitHub (Sep 29, 2024): tcpflow results when host browser loads http://localhost:11434/api/ps ``` 172.017.000.001.35586-172.017.000.002.11434: GET /api/ps HTTP/1.1 Host: localhost:11434 Connection: keep-alive sec-ch-ua: "Google Chrome";v="129", "Not=A?Brand";v="8", "Chromium";v="129" sec-ch-ua-mobile: ?0 sec-ch-ua-platform: "Windows" DNT: 1 Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/129.0.0.0 Safari/537.36 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7 Sec-Fetch-Site: cross-site Sec-Fetch-Mode: navigate Sec-Fetch-User: ?1 Sec-Fetch-Dest: document Accept-Encoding: gzip, deflate, br, zstd Accept-Language: en-US,en;q=0.9 172.017.000.002.11434-172.017.000.001.35586: HTTP/1.1 200 OK Content-Type: application/json; charset=utf-8 Date: Sun, 29 Sep 2024 06:23:28 GMT Content-Length: 13 {"models":[]} ``` tcpflow results when host browser loads http://[::1]:11434/api/ps ``` 172.017.000.001.39736-172.017.000.002.11434: GET /api/ps HTTP/1.1 Host: [::1]:11434 Connection: keep-alive sec-ch-ua: "Google Chrome";v="129", "Not=A?Brand";v="8", "Chromium";v="129" sec-ch-ua-mobile: ?0 sec-ch-ua-platform: "Windows" DNT: 1 Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/129.0.0.0 Safari/537.36 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7 Sec-Fetch-Site: none Sec-Fetch-Mode: navigate Sec-Fetch-User: ?1 Sec-Fetch-Dest: document Accept-Encoding: gzip, deflate, br, zstd Accept-Language: en-US,en;q=0.9 172.017.000.002.11434-172.017.000.001.39736: HTTP/1.1 200 OK Content-Type: application/json; charset=utf-8 Date: Sun, 29 Sep 2024 06:23:53 GMT Content-Length: 13 {"models":[]} ``` tcpflow results when host browser loads http://127.0.0.1:11434/api/ps => Nothing is logged ``` ```
GiteaMirror commented 2026-04-12 15:22:54 -05:00
Author
Owner
Copy Link
Copy Source

@justincranford commented on GitHub (Sep 29, 2024):

tcpflow results when host browser loads http://localhost:11434/api/tags

172.017.000.001.35586-172.017.000.002.11434: GET /api/tags HTTP/1.1
Host: localhost:11434
Connection: keep-alive
sec-ch-ua: "Google Chrome";v="129", "Not=A?Brand";v="8", "Chromium";v="129"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
DNT: 1
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/129.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Sec-Fetch-Site: none
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Accept-Encoding: gzip, deflate, br, zstd
Accept-Language: en-US,en;q=0.9


172.017.000.002.11434-172.017.000.001.35586: HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Date: Sun, 29 Sep 2024 06:26:34 GMT
Content-Length: 344

{"models":[{"name":"llama3.2:latest","model":"llama3.2:latest","modified_at":"2024-09-28T16:19:53.547439642Z","size":2019393189,"digest":"a80c4f17acd55265feec403c7aef86be0c25983ab279d83f3bcd3abbcb5b8b72","details":{"parent_model":"","format":"gguf","family":"llama","families":["llama"],"parameter_size":"3.2B","quantization_level":"Q4_K_M"}}]}

tcpflow results when host browser loads http://[::1]:11434/api/tags

172.017.000.001.39736-172.017.000.002.11434: GET /api/tags HTTP/1.1
Host: [::1]:11434
Connection: keep-alive
sec-ch-ua: "Google Chrome";v="129", "Not=A?Brand";v="8", "Chromium";v="129"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
DNT: 1
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/129.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Sec-Fetch-Site: cross-site
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Accept-Encoding: gzip, deflate, br, zstd
Accept-Language: en-US,en;q=0.9


172.017.000.002.11434-172.017.000.001.39736: HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Date: Sun, 29 Sep 2024 06:27:21 GMT
Content-Length: 344

{"models":[{"name":"llama3.2:latest","model":"llama3.2:latest","modified_at":"2024-09-28T16:19:53.547439642Z","size":2019393189,"digest":"a80c4f17acd55265feec403c7aef86be0c25983ab279d83f3bcd3abbcb5b8b72","details":{"parent_model":"","format":"gguf","family":"llama","families":["llama"],"parameter_size":"3.2B","quantization_level":"Q4_K_M"}}]}

tcpflow results when host browser loads http://127.0.0.1:11434/api/tags => nothing is logged

<!-- gh-comment-id:2381128659 --> @justincranford commented on GitHub (Sep 29, 2024): tcpflow results when host browser loads http://localhost:11434/api/tags ``` 172.017.000.001.35586-172.017.000.002.11434: GET /api/tags HTTP/1.1 Host: localhost:11434 Connection: keep-alive sec-ch-ua: "Google Chrome";v="129", "Not=A?Brand";v="8", "Chromium";v="129" sec-ch-ua-mobile: ?0 sec-ch-ua-platform: "Windows" DNT: 1 Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/129.0.0.0 Safari/537.36 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7 Sec-Fetch-Site: none Sec-Fetch-Mode: navigate Sec-Fetch-User: ?1 Sec-Fetch-Dest: document Accept-Encoding: gzip, deflate, br, zstd Accept-Language: en-US,en;q=0.9 172.017.000.002.11434-172.017.000.001.35586: HTTP/1.1 200 OK Content-Type: application/json; charset=utf-8 Date: Sun, 29 Sep 2024 06:26:34 GMT Content-Length: 344 {"models":[{"name":"llama3.2:latest","model":"llama3.2:latest","modified_at":"2024-09-28T16:19:53.547439642Z","size":2019393189,"digest":"a80c4f17acd55265feec403c7aef86be0c25983ab279d83f3bcd3abbcb5b8b72","details":{"parent_model":"","format":"gguf","family":"llama","families":["llama"],"parameter_size":"3.2B","quantization_level":"Q4_K_M"}}]} ``` tcpflow results when host browser loads http://[::1]:11434/api/tags ``` 172.017.000.001.39736-172.017.000.002.11434: GET /api/tags HTTP/1.1 Host: [::1]:11434 Connection: keep-alive sec-ch-ua: "Google Chrome";v="129", "Not=A?Brand";v="8", "Chromium";v="129" sec-ch-ua-mobile: ?0 sec-ch-ua-platform: "Windows" DNT: 1 Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/129.0.0.0 Safari/537.36 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7 Sec-Fetch-Site: cross-site Sec-Fetch-Mode: navigate Sec-Fetch-User: ?1 Sec-Fetch-Dest: document Accept-Encoding: gzip, deflate, br, zstd Accept-Language: en-US,en;q=0.9 172.017.000.002.11434-172.017.000.001.39736: HTTP/1.1 200 OK Content-Type: application/json; charset=utf-8 Date: Sun, 29 Sep 2024 06:27:21 GMT Content-Length: 344 {"models":[{"name":"llama3.2:latest","model":"llama3.2:latest","modified_at":"2024-09-28T16:19:53.547439642Z","size":2019393189,"digest":"a80c4f17acd55265feec403c7aef86be0c25983ab279d83f3bcd3abbcb5b8b72","details":{"parent_model":"","format":"gguf","family":"llama","families":["llama"],"parameter_size":"3.2B","quantization_level":"Q4_K_M"}}]} ``` tcpflow results when host browser loads http://127.0.0.1:11434/api/tags => nothing is logged ``` ```
GiteaMirror commented 2026-04-12 15:22:55 -05:00
Author
Owner
Copy Link
Copy Source

@justincranford commented on GitHub (Sep 29, 2024):

I noticed something weird.

When host loads http://127.0.0.1:11434/api/tags:

  1. Host browser receives this response body and displays it
{"models":[{"name":"llama2:latest","model":"llama2:latest","modified_at":"2024-02-25T00:15:45.792978629-05:00","size":3826793677,"digest":"78e26419b4469263f75331927a00a0284ef6544c1975b826b15abdaef17bb962","details":{"parent_model":"","format":"gguf","family":"llama","families":["llama"],"parameter_size":"7B","quantization_level":"Q4_0"}},{"name":"mistral:latest","model":"mistral:latest","modified_at":"2024-01-30T23:10:33.623744553-05:00","size":4109865159,"digest":"61e88e884507ba5e06c49b40e6226884b2a16e872382c2b44a42f2d119d804a5","details":{"parent_model":"","format":"gguf","family":"llama","families":["llama"],"parameter_size":"7B","quantization_level":"Q4_0"}}]}
  1. tcpflow doesn't log anything inside the ollama container

I tried loading http://127.0.0.1:11434/api/tags on host system using Chrome, Firefox, and Power Shell curl. Nothing is logged by tcpinfo.

<!-- gh-comment-id:2381130818 --> @justincranford commented on GitHub (Sep 29, 2024): I noticed something weird. When host loads http://127.0.0.1:11434/api/tags: 1. Host browser receives this response body and displays it ``` {"models":[{"name":"llama2:latest","model":"llama2:latest","modified_at":"2024-02-25T00:15:45.792978629-05:00","size":3826793677,"digest":"78e26419b4469263f75331927a00a0284ef6544c1975b826b15abdaef17bb962","details":{"parent_model":"","format":"gguf","family":"llama","families":["llama"],"parameter_size":"7B","quantization_level":"Q4_0"}},{"name":"mistral:latest","model":"mistral:latest","modified_at":"2024-01-30T23:10:33.623744553-05:00","size":4109865159,"digest":"61e88e884507ba5e06c49b40e6226884b2a16e872382c2b44a42f2d119d804a5","details":{"parent_model":"","format":"gguf","family":"llama","families":["llama"],"parameter_size":"7B","quantization_level":"Q4_0"}}]} ``` 2. tcpflow doesn't log anything inside the ollama container I tried loading http://127.0.0.1:11434/api/tags on host system using Chrome, Firefox, and Power Shell curl. Nothing is logged by tcpinfo.
GiteaMirror commented 2026-04-12 15:22:55 -05:00
Author
Owner
Copy Link
Copy Source

@rick-github commented on GitHub (Sep 29, 2024):

So traffic to 127.0.0.1 is not being sent to the container. Do you have a firewall/virus scanner? Is there a proxy? Do you set http_proxy or HTTP_PROXY in the environment? Is there anything else listening on port 11434?

netstat -bano | Select-String -Pattern 11434 -Context 0,1

Is it possible you have multiple ollama servers running on the same port but different IP addresses/interfaces?

<!-- gh-comment-id:2381131377 --> @rick-github commented on GitHub (Sep 29, 2024): So traffic to 127.0.0.1 is not being sent to the container. Do you have a firewall/virus scanner? Is there a proxy? Do you set `http_proxy` or `HTTP_PROXY` in the [environment](https://github.com/ollama/ollama/blob/main/docs/faq.md#setting-environment-variables-on-windows)? Is there anything else listening on port 11434? ``` netstat -bano | Select-String -Pattern 11434 -Context 0,1 ``` Is it possible you have multiple ollama servers running on the same port but different IP addresses/interfaces?
GiteaMirror commented 2026-04-12 15:22:56 -05:00
Author
Owner
Copy Link
Copy Source

@rick-github commented on GitHub (Sep 29, 2024):

What's the result of

http://localhost:11434/api/version
http://[::1]:11434/api/version
http://127.0.0.1:11434/api/version

<!-- gh-comment-id:2381132733 --> @rick-github commented on GitHub (Sep 29, 2024): What's the result of http://localhost:11434/api/version [http://[::1]:11434/api/version](http://[::1]:11434/api/version) http://127.0.0.1:11434/api/version
GiteaMirror commented 2026-04-12 15:22:56 -05:00
Author
Owner
Copy Link
Copy Source

@justincranford commented on GitHub (Sep 29, 2024):

I killed the container and volume. Restarted and ran those API calls. Now ::1 is failing.

http://localhost:11434/api/version

{"version":"0.1.22"}

http://[::1]:11434/api/version

[::1] refused to connect.

http://127.0.0.1:11434/api/version

{"version":"0.1.22"}
<!-- gh-comment-id:2381133299 --> @justincranford commented on GitHub (Sep 29, 2024): I killed the container and volume. Restarted and ran those API calls. Now ::1 is failing. http://localhost:11434/api/version ``` {"version":"0.1.22"} ``` http://[::1]:11434/api/version ``` [::1] refused to connect. ``` http://127.0.0.1:11434/api/version ``` {"version":"0.1.22"} ```
GiteaMirror commented 2026-04-12 15:22:56 -05:00
Author
Owner
Copy Link
Copy Source

@rick-github commented on GitHub (Sep 29, 2024):

You are running a super old version of ollama, not 0.3.12. I suspect that you do indeed have an old ollama server floating around which is intercepting some of the calls that you are making. Have you previously tried installing ollama in WSL (https://github.com/ollama/ollama/issues/6701)?

<!-- gh-comment-id:2381134382 --> @rick-github commented on GitHub (Sep 29, 2024): You are running a super old version of ollama, not 0.3.12. I suspect that you do indeed have an old ollama server floating around which is intercepting some of the calls that you are making. Have you previously tried installing ollama in WSL (https://github.com/ollama/ollama/issues/6701)?
GiteaMirror commented 2026-04-12 15:22:56 -05:00
Author
Owner
Copy Link
Copy Source

@justincranford commented on GitHub (Sep 29, 2024):

I have a theory. Before killing the container, the results I was getting for http://127.0.0.1/api/tag and http://127.0.0.1/api/ps were served from cache.

It's weird that 2 browsers and 1 CLI would get same cached results. That might imply caching is being done by Windows networking or Docker networking, but not sure.

If my theory is correct, I think the HTTP headers for /api/tag and /api/ps might not be telling clients to disable caching.

<!-- gh-comment-id:2381135062 --> @justincranford commented on GitHub (Sep 29, 2024): I have a theory. Before killing the container, the results I was getting for http://127.0.0.1/api/tag and http://127.0.0.1/api/ps were served from cache. It's weird that 2 browsers and 1 CLI would get same cached results. That might imply caching is being done by Windows networking or Docker networking, but not sure. If my theory is correct, I think the HTTP headers for /api/tag and /api/ps might not be telling clients to disable caching.
GiteaMirror commented 2026-04-12 15:22:57 -05:00
Author
Owner
Copy Link
Copy Source

@justincranford commented on GitHub (Sep 29, 2024):

I compared response header for these API calls. Cache-control response header is missing for 2 and 3.

  1. /api/version => cache-control: max-age=0
  2. /api/tag => No cache-control header
  3. /api/ps => No cache-control header
<!-- gh-comment-id:2381135895 --> @justincranford commented on GitHub (Sep 29, 2024): I compared response header for these API calls. Cache-control response header is missing for 2 and 3. 1. /api/version => cache-control: max-age=0 2. /api/tag => No cache-control header 3. /api/ps => No cache-control header
GiteaMirror commented 2026-04-12 15:22:58 -05:00
Author
Owner
Copy Link
Copy Source

@justincranford commented on GitHub (Sep 29, 2024):

I tried building ollama locally and adding the missing response header.

I put it in a PR.
https://github.com/ollama/ollama/pull/7030

<!-- gh-comment-id:2381256236 --> @justincranford commented on GitHub (Sep 29, 2024): I tried building ollama locally and adding the missing response header. I put it in a PR. https://github.com/ollama/ollama/pull/7030
GiteaMirror commented 2026-04-12 15:22:58 -05:00
Author
Owner
Copy Link
Copy Source

@rick-github commented on GitHub (Sep 29, 2024):

Isn't this a problem with your caching proxy, though? It's caching /api/tag and /api/ps without adding headers to indicate to the client that data may be stale, yet it's adding a header to /api/version.

<!-- gh-comment-id:2381270784 --> @rick-github commented on GitHub (Sep 29, 2024): Isn't this a problem with your caching proxy, though? It's caching `/api/tag` and `/api/ps` without adding headers to indicate to the client that data may be stale, yet it's adding a header to `/api/version`.
GiteaMirror commented 2026-04-12 15:22:58 -05:00
Author
Owner
Copy Link
Copy Source

@justincranford commented on GitHub (Sep 30, 2024):

I found the problem. I found an old version of ollama 0.1.22 running inside the WSL2 VM.

  1. Windows Client (Firefox, Chrome, Power Shell curl)
  2. WSL2 VM (Ubuntu) => ollama 0.1.22 daemon is listening to 127.0.0.1:11434; only IPv4 loopback
  3. Docker Container => ollama 0.3.12 container is listening to 0.0.0.0:11434; all interfaces

So, IPv4 calls are being intercepted and serviced by the 0.1.22 daemon, and only IPv6 calls were getting through to the 0.3.12 container.

Weird. I must have done an old install with this command, back when 0.1.22 was latest. And I installed it inside the WSL2 VM itself, not in a container running on that VM.

curl https://ollama.ai/install.sh | sh
<!-- gh-comment-id:2384193263 --> @justincranford commented on GitHub (Sep 30, 2024): I found the problem. I found an old version of ollama 0.1.22 running inside the WSL2 VM. 1. Windows Client (Firefox, Chrome, Power Shell curl) 2. WSL2 VM (Ubuntu) => ollama 0.1.22 daemon is listening to `127.0.0.1:11434`; only IPv4 loopback 3. Docker Container => ollama 0.3.12 container is listening to `0.0.0.0:11434`; all interfaces So, IPv4 calls are being intercepted and serviced by the 0.1.22 daemon, and only IPv6 calls were getting through to the 0.3.12 container. Weird. I must have done an old install with this command, back when 0.1.22 was latest. And I installed it inside the WSL2 VM itself, not in a container running on that VM. ``` curl https://ollama.ai/install.sh | sh ```
GiteaMirror commented 2026-04-12 15:22:58 -05:00
Author
Owner
Copy Link
Copy Source

@justincranford commented on GitHub (Sep 30, 2024):

I manually cleaned up that old ollama 0.1.22 from the WSL2 VM. Everything is working like it shoud.

I still think the Cache-Control header should be added to /api/tags and /api/ps responses, but that would be a different problem, not related to my issue.

Sorry for the confusion. It was a very weird issue. I guess a daemon and container in the WSL2 host can listen to same interface and port (IPv4 loopback 11434), without any error and quietly intercepting the traffic.

<!-- gh-comment-id:2384210266 --> @justincranford commented on GitHub (Sep 30, 2024): I manually cleaned up that old ollama 0.1.22 from the WSL2 VM. Everything is working like it shoud. I still think the Cache-Control header should be added to /api/tags and /api/ps responses, but that would be a different problem, not related to my issue. Sorry for the confusion. It was a very weird issue. I guess a daemon and container in the WSL2 host can listen to same interface and port (IPv4 loopback 11434), without any error and quietly intercepting the traffic.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
amd
api
app
bug
build
cli
cloud
compatibility
context-length
create
docker
documentation
embeddings
feature request
feedback wanted
good first issue
gpt-oss
gpu
harmony
help wanted
image
install
intel
js
launch
linux
macos
memory
mlx
model
needs more info
networking
nvidia
ollama.com
performance
pull-request
Mirrored from GitHub Pull Request
 python
question
registry
rendering
thinking
tools
top
vulkan
windows
wsl
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/ollama#4453