Ollama 서버에 연결되지 않을 때 확인할 것
Ollama에서 서버 연결 오류가 나면 먼저 오류 문구를 남기세요. Ollama 명령을 찾지 못한 것인지, 실행 중인 서버에 연결하지 못한 것인지에 따라 확인할 곳이 다릅니다.
이 글은 Windows에 이미 설치된 Ollama의 기본 로컬 연결을 점검하는 안내입니다. 명령을 찾을 수 있는지, 요청 주소가 맞는지, 연결을 받는 번호인 포트를 어떤 프로그램이 쓰는지 차례로 살펴봅니다. 기본 주소의 포트를 의도한 기존 Ollama 서버가 쓰는지 확인하기 전에는 HTTP 조회를 하지 않습니다. 서버를 새로 시작하거나 포트를 바꾸지 않으며, 모델 실행·다운로드·클라우드 로그인도 하지 않습니다.
아래 여섯 사례는 다음에 확인할 내용을 고르는 설명용 가상 예제입니다.
실행 파일 검색과 서버 연결을 먼저 분리하기
새 CMD에서 where ollama.exe의 검색 결과가 없거나 프로그램을 인식하지 못한다면 명령 검색 단계부터 확인합니다. 설치 출처와 경로가 확인되지 않은 동명 파일을 실행하지 않습니다. 자세한 PATH 점검은 CMD에서 Ollama 명령을 찾지 못할 때 확인하기에 있습니다.
본인이 확인한 공식 설치본을 사용할 수 있을 때 CMD에서 도움말과 버전 메시지를 기록합니다.
ollama serve --help
ollama --versionserve --help는 도움말 확인입니다. ollama serve로 서버를 시작하는 명령과 구별하세요. 공식 CLI 문서는 도움말에서 서버 환경 변수 안내를 확인할 수 있다고 설명합니다. Ollama CLI 문서
도움말을 열 수 있으면 적어도 그 실행 파일을 불러오는 단계의 단서가 있습니다. 그러나 서버 대기, 모델 준비, GPU 실행까지 통과한 것은 아닙니다. 버전 확인에 경고나 연결 관련 메시지가 함께 나왔다면 숫자만 복사하지 말고 전체 메시지를 남깁니다. --version 출력 하나를 아래 서버 점검의 대체 증거로 쓰지 않습니다.
요청 도구가 어느 주소를 사용하는지 적기
Ollama의 기본 서버는 IPv4 루프백 127.0.0.1의 11434 포트에 바인딩됩니다. OLLAMA_HOST로 구성이 달라질 수 있으므로 원래 오류를 낸 도구의 주소와 현재 기본값이 같다고 가정하지 않습니다. Ollama FAQ
Windows PowerShell에서 현재 셸이 가진 이 변수만 조회할 수 있습니다.
[Environment]::GetEnvironmentVariable('OLLAMA_HOST', 'Process')이 조회는 현재 PowerShell의 환경값입니다. 이미 실행 중인 Ollama 서버나 별도 편집기·웹 앱의 환경을 직접 읽어 주는 것이 아닙니다. 원래 실패한 도구에 자체 연결 설정이 있다면 그 설정과 오류 주소를 따로 기록하세요. 환경 변수가 비어 있다고 다른 앱의 연결 대상까지 기본값으로 확정하지 않습니다.
이 글의 뒤쪽 HTTP 명령은 기본 IPv4 루프백과 11434를 의도한 경우에만 사용합니다. 원래 대상이 다른 포트·WSL·컨테이너·원격 서버라면 같은 범위의 검사가 아니므로 그 차이를 기록하고 여기서 멈춥니다. 방화벽, 프록시, 서버 바인딩을 바꾸는 조치는 포함하지 않습니다.
대기 포트와 소유 프로세스 확인하기
Ollama가 설치되어 있어도 백그라운드 앱이 현재 실행 중인지는 별도입니다. 반대로 11434 포트가 열려 있어도 다른 프로그램이 소유하고 있을 수 있습니다. Windows PowerShell에서 다음 읽기 전용 조회를 사용합니다.
$connections = Get-NetTCPConnection -LocalPort 11434 -State Listen
$connections | Select-Object LocalAddress, LocalPort, State, OwningProcess
$connections | ForEach-Object { Get-Process -Id $_.OwningProcess } |
Select-Object Id, ProcessName, PathGet-NetTCPConnection은 주소·포트·상태와 소유 프로세스 ID를 조회합니다. Get-Process에서는 해당 ID의 프로세스를 대조합니다. 프로세스가 그 사이 종료되거나 경로를 조회할 권한이 없으면 오류나 빈 경로가 나올 수 있습니다. 이를 ‘Ollama가 아님’이나 ‘안전함’으로 바꾸지 않습니다. Microsoft TCP 조회, Microsoft 프로세스 조회
소유 ID, 실행 파일 경로와 본인이 확인한 설치 경위를 함께 봅니다. 이름이 Ollama와 비슷하다는 이유만으로 신뢰하지 않습니다. 조회 결과가 없거나 조회 오류가 나면 당시 출력과 시각을 남기세요. 대기 항목을 관찰하지 못했다는 사실만으로 미설치·보안 차단·앱 종료 중 하나를 확정할 수 없습니다.
주소도 확인합니다. 127.0.0.1과 ::1은 서로 다른 주소 계열이고, 0.0.0.0처럼 여러 인터페이스를 포함하는 바인딩은 기본 루프백 전용과 같은 범위가 아닙니다. 이 점검을 통과시키기 위해 바인딩을 넓히거나 다른 프로세스를 강제 종료하지 않습니다. 의도하지 않은 공개 범위나 모르는 소유자를 발견하면 HTTP 조회를 진행하지 않고 담당자에게 확인합니다.
모델을 호출하지 않고 버전 API 관찰하기
기본 루프백의 포트 소유자가 의도한 기존 Ollama 서버임을 확인했고, 해당 PC에서 curl.exe를 사용할 수 있을 때만 새 CMD에서 다음을 한 번 조회합니다. curl.exe가 없다면 이 단계는 미실행으로 남기고 임의 도구 설치로 바꾸지 않습니다.
curl.exe -q --noproxy "*" --max-time 5 --include http://127.0.0.1:11434/api/version
echo %ERRORLEVEL%-q는 첫 옵션으로 두어 기본 curl 설정 파일을 읽지 않게 합니다. --noproxy "*"는 이 요청에 프록시를 쓰지 않도록 하고, --max-time 5는 전송 시간 제한을 둡니다. --include로 HTTP 헤더와 본문을 함께 봅니다. 리디렉션 추적 옵션과 재시도 옵션은 넣지 않았습니다. PC나 조직의 프록시 설정을 변경하는 명령은 아닙니다. curl 공식 명령 문서
echo는 요청 직후 실행해야 바로 앞 종료 코드를 읽습니다. curl 종료 코드와 HTTP 상태는 다른 값입니다. 이 명령에는 HTTP 오류를 curl 실패로 만드는 옵션이 없으므로 종료 코드 0만 보고 정상 API라고 판정하지 않습니다. 받은 HTTP 상태와 실제 본문을 함께 확인하세요.
공식 API 문서에서 GET /api/version은 서버 버전을 조회하는 경로입니다. 업무 입력이나 모델 생성 요청을 넣지 않습니다. 문서에 실린 응답 예의 버전 번호를 내 PC의 결과로 베끼지 마세요. Ollama v0.35.1의 API 문서
- HTTP 응답을 얻지 못함: 연결 대상·현재 대기 상태·실제 오류를 다시 대조합니다
- HTTP 응답이 있지만 상태나 내용이 예상 API와 다름: 서비스 정체와 요청 경로를 조사합니다
- 정상 상태와 문자열 형태의 실제 version 필드를 관찰함: 해당 시점의 버전 API 응답을 기록합니다
마지막 경우도 모델 추론 성공, 인증 전체, 장비 적합성의 증거는 아닙니다. 원래 도구가 localhost 이름이나 다른 주소를 사용했다면 이번 숫자 주소의 결과와 별도로 비교합니다. 한 경로가 통과했다고 원래 도구의 연결 문제가 해결된 것은 아닙니다.
여섯 가상 관찰에서 조사 범위를 고르기
다음 표는 사람이 만든 관찰 조건입니다. 실제 HTTP 상태·JSON 본문·Ollama 성공 출력·측정값을 만들어 넣은 표가 아닙니다. 각 조건에서 보류할 판단을 연습합니다.
| 가상 사례 | 주어진 관찰 조건 | 다음 조사 범위 |
|---|---|---|
| A | 실행 파일 검색을 통과하지 못함 | 명령 검색·설치 위치부터 확인 |
| B | 실행 파일 도움말은 열리지만 대기 포트를 관찰하지 못함 | 기존 앱 실행 상태·시각·로그 확인 |
| C | 대기 포트는 있으나 소유 실행 파일이 미확인 | 서비스 정체 확인 전 추가 요청 보류 |
| D | 소유자는 확인했으나 버전 API 관찰이 계약에 맞지 않음 | HTTP 상태·요청 경로·서버 로그 대조 |
| E | 버전 API 관찰 조건은 맞고 조회한 모델 목록은 비어 있음 | 서버 관찰과 모델 준비 상태를 분리 |
| F | 기본 루프백 관찰은 됐으나 원래 도구의 요청 대상이 다름 | 원래 도구의 연결 설정 확인 |
E에서 목록이 비어 있다는 조건은 다운로드가 성공했다는 뜻이 아닙니다. 이미 준비된 서버의 ollama ls를 확인했을 때도 서버 대상과 실제 목록을 같이 기록해야 합니다. F에서 기본 포트의 서버를 재설치해도 원래 앱의 주소 불일치를 설명하지 못할 수 있습니다.
Linux Python 3.12.14에서 위 여섯 조건의 분류와 ‘모델 응답은 미검증’ 유지 여부를 실제 검사했습니다. 검사는 합성 기록만 읽었고 HTTP 서버, 네트워크 요청, Ollama 프로세스를 사용하지 않았습니다. 실제 API 성공·실패를 CSV로 만드는 Python 루프백 REST 점검 실습과는 검사 대상이 다릅니다.
오류를 조사할 때 남길 기록
기존 앱의 상태와 로그를 확인할 때 공식 Windows 문서의 %LOCALAPPDATA%\Ollama 위치를 참고할 수 있습니다. 로그에서 필요한 시각과 오류만 확인하고 계정·내부 경로·업무 자료를 불필요하게 공유하지 않습니다. Ollama Windows 문제 해결 안내
[Ollama 연결 범위 기록]
관찰 날짜와 시간대 / Windows 버전:
원래 실패한 도구와 정확한 오류 문구:
확인한 실행 파일 위치와 설치 출처:
serve --help 결과 / --version 전체 메시지:
원래 도구의 호스트·포트·경로:
현재 PowerShell의 OLLAMA_HOST 값 또는 빈 출력:
조회한 LocalAddress·LocalPort·State·OwningProcess:
대조한 실행 파일 경로 / 확인 불가 이유:
HTTP 조회 실행 여부와 대상:
실제 curl 종료 코드 / HTTP 상태:
실제 version 필드 또는 실제 오류:
모델 목록의 연결 대상 / 결과 또는 미실행:
실행 파일·서버·모델 중 아직 미확인인 범위:
이번 조사에서 바꾼 설정: 없음현재 공개 최신 릴리스는 확인 시 Ollama v0.35.1이었습니다. 공개 최신 버전, 실행 파일이 보고한 메시지, 버전 API가 보고한 서버 값은 구분해서 보관합니다. 실제 설치 버전을 이 글에서 관찰하지는 않았습니다.
루프백 API가 응답해도 최종 모델 처리가 로컬이라고 확정하지 않습니다. Ollama는 로컬 서버를 거쳐 클라우드 모델을 사용할 수 있습니다. 이 글에서는 버전만 조회하며 모델 처리 위치를 인증하지 않습니다. Ollama API 소개, 로컬·웹·API 실행과 자료 전달 책임 안내
원인을 확정할 근거가 부족하면 다음 관찰 대상만 정해도 됩니다. 앱 재시작·설정 변경·다운로드 같은 후속 조치는 관찰 기록으로 범위를 좁힌 뒤 별도로 검토하세요. 기술 기준일은 2026년 10월 4일 KST이며 Windows와 Ollama에서의 실제 실행은 미검증입니다.
작성자 소개
