【PR】この記事にはA8.netのアフィリエイト広告を含みます。
先に結論：XServer VPS上のOllama 0.33.2で3つの安全な到達性条件を試しました。同一Docker networkだけで使う構成はpeerから接続成功・host待受なし、localhost公開は127.0.0.1からHTTP 200・VPS公開IPv4から接続拒否でした。11434をインターネットへ開かず使えるため、判定は解決です。
- Ollamaの11434番ポートをVPSで公開しても大丈夫？
- Dockerの「EXPOSE」と「ports」は何が違う？
- XServer VPSでどんな実験をした？
- 4つのbind・publish条件はどうなった？
- 同一DockerネットワークだけでOllamaを使える？
- OLLAMA_HOSTを127.0.0.1にするとどうなる？
- VPS localhostだけに公開できた？
- なぜ0.0.0.0:18027を実際に起動しなかった？
- 実験中に何が失敗した？
- CPU・RAM・ストレージへの影響は？
- 本番サービスと後片付けは？
- AIスマホ調査システムではどの構成を選ぶ？
- 初心者が迷いそうなポイントは？
- XServer VPSでこの悩みはどこまで解決した？
- よくある質問
- 最新条件の確認先
Ollamaの11434番ポートをVPSで公開しても大丈夫？
raw APIの直接公開は避けるべきです。認証やrate limitを別に設けず第三者が到達できれば、model一覧の取得や推論requestを受ける入口になります。
悩みの起点にしたReddit「I got tired of seeing exposed Ollama ports on Shodan」では、Ollama、n8n、Open WebUIのraw portが公開されたinstanceを見かけるという問題が語られています。
Ollama公式FAQによると、Ollamaは標準で127.0.0.1:11434へbindし、networkへ公開する場合はOLLAMA_HOSTを変更します。
Dockerの「EXPOSE」と「ports」は何が違う？
container内で11434を使うことと、VPSの11434を公開することは別です。同一bridge networkのcontainer同士は、hostへ-pしなくてもcontainer portへ接続できます。
Docker公式のPort publishingは、IPを省略した-p 8080:80がhostの全addressへpublishされ、外部へ到達可能になり得ると警告しています。127.0.0.1を明示するとDocker hostだけに制限できます。
XServer VPSでどんな実験をした？
| 項目 | 実測条件 |
|---|---|
| VPS | XServer VPS、4 vCPU、4GB RAM、150GB |
| OS | Ubuntu 26.04 |
| Docker | 29.7.2 |
| Ollama | ollama/ollama:0.33.2 |
| container port | 11434 |
| localhost test | 127.0.0.1:18027 → 11434 |
| 上限 | 0.5 CPU、512MiB RAM、追加swapなし、PID 128 |
| model | 未load、/api/tagsだけ |
本物のOllama imageを起動しましたが、model推論ではなくAPIの到達性だけを測りました。実験用portをpublicへ開くことはせず、危険なall-interface設定はcontainerを起動する前のinspectで止めています。
4つのbind・publish条件はどうなった？
| 構成 | 利用元 | 結果 | host待受 |
|---|---|---|---|
| OLLAMA_HOST=127.0.0.1、publishなし | 同一networkのpeer | 接続拒否 | なし |
| OLLAMA_HOST=0.0.0.0、publishなし | 同一internal network | 成功、models=[] | なし |
| 127.0.0.1:18027をpublish | VPS localhost | HTTP 200、1.235ms | 127.0.0.1だけ |
| 同上 | VPS公開IPv4 | 接続拒否、0.160ms | 0.0.0.0なし |
| 0.0.0.0:18027設定 | 起動前inspect | HostIp=0.0.0.0 | 安全のため起動せず |
同一DockerネットワークだけでOllamaを使える？
使えました。OLLAMA_HOST=0.0.0.0:11434でOllamaを起動し、同じ--internal networkの別containerから/api/tagsを取得すると、302.488msで{"models":[]}が返りました。
host側のport bindingは空objectで、ssにも11434は出ません。アプリcontainerからだけOllamaを使うなら、Composeのports:自体を省き、同一networkのservice名で接続するのが最も単純です。
OLLAMA_HOSTを127.0.0.1にするとどうなる？
Ollama自身のcontainer内からは利用できますが、別containerが172.21.0.2:11434へ接続すると456.980msでConnection refusedになりました。
「portをpublishしていない」だけでなく、application自体のbind addressも到達範囲を決めます。複数container構成なら0.0.0.0が必要ですが、hostへportsを出さないことが重要です。
VPS localhostだけに公開できた？
できました。127.0.0.1:18027:11434でpublishすると、Docker inspectはHostIp 127.0.0.1を示し、ssも127.0.0.1:18027だけを表示しました。
VPS内のhttp://127.0.0.1:18027/api/tagsはHTTP 200、1.235msです。同じVPSから公開IPv4の18027へ接続すると0.160msで拒否されました。
実際の11434を使わず18027へmappingしたのは、既存構成との衝突を避け、実験portを識別しやすくするためです。Dockerのbind範囲の挙動は同じです。
なぜ0.0.0.0:18027を実際に起動しなかった？
一次情報を取るために危険なpublic listenerを作る必要はないからです。docker create -p 0.0.0.0:18027:11434まで行い、inspectでHostIpが0.0.0.0になることを確認して、起動前に削除しました。
Docker公式仕様でも、host IPを省略したpublishは全interfaceが既定です。安全な代替2方式は実際に起動・通信確認し、危険な方式は設定preflightだけに分けました。
実験中に何が失敗した？
初回は4caseすべてを--internal networkに置きました。localhost publishのHostConfigは正しく見えましたが、hostからは接続拒否でlistenerも現れませんでした。
--internalがhost publishまで制限し、application bindとの比較に別条件が混ざっていました。内部container通信2caseを終えた後、test networkを通常bridgeに作り直してlocalhost publishを再測定しました。再実行でlocalhost HTTP 200、公開IPv4接続拒否を確認できました。
CPU・RAM・ストレージへの影響は？
| case | cgroup peak RAM | CPU |
|---|---|---|
| app loopback | 43.42MiB | 0.363230秒 |
| Docker internal | 42.81MiB | 0.345622秒 |
| host localhost | 45.92MiB | 0.387255秒 |
modelをloadしていないため、これは待受serverだけの値です。host MemAvailableは3272.27MiBから3245.85MiB、root disk差は65,536 byteでした。既に保存されていたOllama imageを再利用しています。
本番サービスと後片付けは？
公開/health/readyは前・実験中・後の全3回でHTTP 200、database=ok、artifact_storage=okでした。本番Caddy、FastAPI、PostgreSQLの停止や再起動はありません。
test container、匿名volume、test networkを全削除しました。dangling volumeは前後0件、11434/18027 listenerも前後0件です。
AIスマホ調査システムではどの構成を選ぶ？
VPS内のAPIだけがOllamaを使うなら内部network・portsなしを選びます。FastAPIからhttp://ollama:11434へ接続し、Ollamaをpublic ingressから分離します。
host processから必要ならlocalhost bindを使います。自宅workerから必要な場合もraw 11434を直接公開せず、次のいずれかを使います。
- VPSの認証付きFastAPIがOllamaを代理する。
- CaddyでHTTPS、認証、rate limit、access logを付ける。
- WireGuardやTailscale等のprivate overlay networkを使う。
- 自宅workerがVPSへoutbound pollingし、inbound portを増やさない。
- XServer VPSのpacket filterでも不要portを閉じる。
初心者が迷いそうなポイントは？
EXPOSE 11434とports: 11434:11434は同じではない。11434:11434はhost IP省略のため全interface公開になり得る。127.0.0.1:11434:11434ならhost localhost限定になる。- 別containerから使うならOllama側はcontainer interfaceへbindする必要がある。
- Ollamaを0.0.0.0へbindしても、hostへport publishしなければ同じ意味のpublic公開にはならない。
- localhost bindだけに頼らず、packet filterと
ss・docker psも確認する。
XServer VPSでこの悩みはどこまで解決した？
判定は解決です。同一Docker network限定とhost localhost限定の2方式を実通信で確認できました。どちらもVPS公開IPv4に11434/18027を開かず、本番serviceも正常でした。
外部端末からraw APIを使う認証構成、IPv6、VPN、Caddy経由のrate limitは未検証です。「閉じたままVPS内で使える」ことと「安全に外部公開できる」ことは分けて考える必要があります。
よくある質問
Q. Docker Composeのportsから11434を消してもFastAPIから使えますか？
A. 同じDocker networkに接続し、Ollamaがcontainer interfaceへbindしていればservice名で使えます。今回もpublishなしでpeerから成功しました。
Q. OLLAMA_HOST=0.0.0.0は危険ですか？
A. それだけでhostのpublic portが開くわけではありません。ただし同じnetwork内の到達範囲は広がるため、不要なcontainerを同居させないことが重要です。
Q. -p 11434:11434は何が問題ですか？
A. host IPを省略するとDockerは原則として全host addressへpublishします。VPS firewallの状態によってはインターネットから到達可能になります。
Q. localhost bindなら完全に安全ですか？
A. public exposureを減らせますが、host上の他processは接続できます。OS権限、認証、firewall、ログも必要です。
Q. Ollama待受だけでRAMはどれくらいでしたか？
A. 今回のcgroup peakは42.81〜45.92MiBでした。modelをloadしていない値なので、推論時RAMとは別です。
実験日：2026年9月2日。数値は筆者が契約中のXServer VPS 4GB環境における単発の実測です。契約plan、Docker network、firewall、IPv6設定、software versionにより結果は変わります。
コメント