「NginxでリバースプロキシをかけてHTTPS化したいが、設定ファイルの正しい書き方がわからない」
そんな悩みを抱えるインフラ担当者やLinux管理者は少なくない。OllamaはデフォルトでHTTPの11434番ポートにバインドしており、設定を変えずに公開するとLAN内の誰もが認証なしにAPIを呼べる状態になる。
この記事では、Nginxをリバースプロキシとして前段に設置し、HTTPS化・Basic認証・UFWによるポート制御まで一通り設定する手順を解説する。Ubuntu Server 22.04/24.04を前提にした実践的な内容だ。
Ollamaをチームへ安全に展開したい管理者は、ぜひ最後まで読んでほしい。
この記事のポイント
・OllamaはデフォルトでHTTP 11434番・認証なし。本番公開前に必ずNginxリバースプロキシを挟む
・systemdのoverride.confで OLLAMA_HOST=127.0.0.1 を設定し、Ollamaを外部バインドから切り離す
・Nginxの proxy_pass http://127.0.0.1:11434; でHTTPS転送とBasic認証を追加し安全に提供する
・UFWで11434番を閉じ443番のみを許可すると「Nginxが入口・認証が門番・UFWが外壁」の多層防御が完成する
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
OllamaをそのままLAN公開すると起きること
OllamaをUbuntu Serverにインストールした直後、プロセスはポート11434番で全インターフェース（0.0.0.0）にリッスンしている。この状態でサーバーのIPアドレスが分かれば、LAN内の誰もが次のコマンド一本で認証なしにAPIを叩ける。
# LAN内の別PCからOllamaホストのIPへ直接アクセス $ curl http://192.168.1.100:11434/api/tags {"models":[{"name":"llama3.3:70b-instruct-q4_0","modified_at":"2026-06-29T10:23:11Z",...}]}
/api/generate や /api/chat エンドポイントへのリクエストも自由に送れる。ローカルLLMを導入する目的の一つは「機密データを外部に出さない」ことにある。認証なしで公開すると、その前提が社内ネットワーク内で崩れてしまう。
社内にローカルLLMを導入する背景と情報漏えいリスクの整理については、社内でChatGPTが使えないときの代替手段｜機密データを守るローカルLLMという選択肢でも詳しく触れている。まだ読んでいない方はあわせて参照してほしい。
本記事ではこのリスクを解消するために、Nginx・HTTPS・Basic認証・UFWを組み合わせた多層防御を一から構築する。
NginxをUbuntu Serverにインストールする
リバースプロキシとして使うNginxを導入する。既にインストール済みの環境はこのh2をスキップしてよい。1. パッケージをインストールする
$ sudo apt update $ sudo apt install nginx -y $ sudo systemctl enable nginx $ sudo systemctl start nginx $ nginx -v nginx version: nginx/1.24.0 (Ubuntu)
systemctl enable でサーバー再起動後も自動起動するよう設定しておく。Nginxのバージョンは
nginx -v で確認できる。Ubuntu 22.04/24.04では1.18系または1.24系がインストールされる。
2. 動作確認する
$ sudo systemctl status nginx * nginx.service - A high performance web server and a reverse proxy server Loaded: loaded (/lib/systemd/system/nginx.service; enabled) Active: active (running) since Mon 2026-06-29 10:00:00 UTC; 30s ago
Active: active (running) が表示されれば正常だ。UFWが有効な環境では
sudo ufw allow 'Nginx HTTP' を実行してポート80番を一時的に開けておく。ブラウザから
http://<サーバーIP>/ にアクセスし「Welcome to nginx!」が表示されれば準備完了だ。
Ollamaをlocalhostのみに制限する（OLLAMA_HOST設定）
Nginxを前段に置く前に、Ollama自体が外部から直接アクセスを受け付けないようにしなければならない。OLLAMA_HOST 環境変数を 127.0.0.1 に設定することで、Ollamaのバインドをループバックインターフェースだけにできます。Ubuntu ServerでOllamaを構築した手順に沿ってインストールした場合、Ollamaはsystemdサービスとして動いているはずだ。このとき環境変数を追加する最も安全な方法がoverride.confの利用だ。
1. systemdのoverride.confを作成する
ollama.service 本体を直接編集すると apt upgrade で上書きされる可能性がある。override.confを使えば本体ファイルを維持したまま設定を追加できる。$ sudo mkdir -p /etc/systemd/system/ollama.service.d $ sudo nano /etc/systemd/system/ollama.service.d/override.conf
[Service] Environment="OLLAMA_HOST=127.0.0.1"
2. Ollamaを再起動してバインドアドレスを確認する
$ sudo systemctl daemon-reload $ sudo systemctl restart ollama $ sudo ss -tlnp | grep 11434 LISTEN 0 4096 127.0.0.1:11434 0.0.0.0:* users:(("ollama",pid=5678,fd=3))
127.0.0.1:11434 と表示されれば成功だ。0.0.0.0:11434 のままなら daemon-reload を忘れているか、override.confの記述が誤っている。ここまでの設定でLAN内の別PCから
curl http://192.168.1.100:11434/ を叩いても接続拒否になるはずだ。確認しておくと安心できる。
Nginxのリバースプロキシ設定を作成する
Ollamaがlocalhostのみで動くようになったら、Nginxがその前段でリクエストを受け取り転送する設定を作る。1. サイト設定ファイルを作成する
$ sudo nano /etc/nginx/sites-available/ollama
server_name は実際のドメインまたはサーバーのIPに変える。server { listen 80; server_name ollama.example.com; location / { proxy_pass http://127.0.0.1:11434; proxy_http_version 1.1; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_read_timeout 300s; proxy_buffering off; } }
proxy_read_timeout 300s はLLMが長い回答を生成する際のタイムアウト対策だ。Nginxのデフォルトは60秒だが、大きなモデルの推論は数分かかることがある。proxy_buffering off はストリーミングレスポンスをリアルタイムに転送するために必要な設定だ。Open WebUIやAPIクライアントのストリーミング表示が正しく動く。
2. 設定を有効化してNginxを再起動する
$ sudo ln -s /etc/nginx/sites-available/ollama /etc/nginx/sites-enabled/ $ sudo nginx -t nginx: configuration file /etc/nginx/nginx.conf test is successful $ sudo systemctl reload nginx
nginx -t で文法エラーが検出される。test is successful を確認してからreloadする習慣を付けると、設定ミスで本番Nginxが止まるトラブルを防げる。この段階ではまだHTTPだが、
curl http://ollama.example.com/api/tags でレスポンスが返ってくれば転送設定は正しく機能している。
certbotでHTTPS証明書を取得してNginxに適用する
HTTPのままでは通信内容が平文で流れる。Let's Encryptの無料証明書でHTTPS化する。前提条件として、ドメインが取得済みで、DNS AレコードがこのサーバーのIPを向いていることが必要だ。
社内専用で外部ドメインを持たない場合はこのh2をスキップし、後述の自己署名証明書の補足を参照してほしい。
1. certbotをインストールする
$ sudo apt install certbot python3-certbot-nginx -y
2. 証明書を取得してNginxに自動適用する
$ sudo certbot --nginx -d ollama.example.com # メールアドレス入力・利用規約への同意を求められる # 完了後、/etc/nginx/sites-available/ollama に443番ブロックが自動追加される Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/ollama.example.com/fullchain.pem
certbot --nginx オプションを使うと、Nginxの設定ファイルをcertbotが自動編集してHTTPSリダイレクトまで設定してくれる。手動で証明書パスを書く必要がないため、記述ミスのリスクが低い。
3. 自動更新が機能していることを確認する
Let's Encryptの証明書は90日で失効する。certbotインストール時にsystemdタイマーが自動登録されるため、通常は手動更新が不要だ。$ sudo certbot renew --dry-run Congratulations, all simulated renewals succeeded. The following certs are ready: /etc/letsencrypt/live/ollama.example.com/fullchain.pem
simulated renewals succeeded が表示されれば自動更新は正常だ。社内環境でドメインを持たない場合は、自己署名証明書でHTTPS化する方法もある。ただしブラウザに「接続は安全ではありません」の警告が出るため、チームメンバーへの事前説明が必要だ。本番・外部公開環境では必ずLet's Encryptの正規証明書を使うことを推奨する。
htpasswdでBasic認証を追加する
HTTPSが確立したら、次は認証を追加する。Basic認証はシンプルだが、HTTPS前提であればパスワードが平文で流れることなく、実務上十分な保護になる。チームメンバーごとに個別アカウントを発行するとアクセス管理が容易になる。
1. apache2-utilsをインストールする
$ sudo apt install apache2-utils -y
htpasswd コマンドがこのパッケージに含まれている。Nginxと直接の依存関係はないが、Basic認証のパスワードファイル生成に必要だ。
2. パスワードファイルを作成する
# 最初のユーザー（-c でファイル新規作成） $ sudo htpasswd -c /etc/nginx/.htpasswd llmuser01 New password: Re-type new password: Adding password for user llmuser01 # 2人目以降（-c を外して追記） $ sudo htpasswd /etc/nginx/.htpasswd llmuser02 Adding password for user llmuser02
-c オプションはファイルを新規作成するフラグだ。2人目に -c を付けると既存ファイルが上書きされてユーザーが消える。パスワードはbcryptでハッシュ化されて保存されるため、.htpasswdファイルが万一漏えいしても平文パスワードは分からない。
ユーザーを削除したい場合は
sudo htpasswd -D /etc/nginx/.htpasswd llmuser01 で削除できる。
3. Nginx設定にBasic認証を追加する
/etc/nginx/sites-available/ollama を開き、location / ブロック内の先頭に2行を追加する。location / { auth_basic "Ollama - Team Access"; auth_basic_user_file /etc/nginx/.htpasswd; proxy_pass http://127.0.0.1:11434; proxy_http_version 1.1; # 以下は変更なし }
$ sudo nginx -t && sudo systemctl reload nginx nginx: configuration file /etc/nginx/nginx.conf test is successful
https://ollama.example.com/ を開くと認証ダイアログが表示される。curlでは -u ユーザー名:パスワード オプションで認証できる。
UFWでポートアクセスを制御する
Nginxの前段でHTTPS・認証が整ったら、最後にUFWでポート制御を追加して多層防御を完成させる。Nginxは443番でリクエストを受け取り、内部でlocalhost:11434へ転送する。外部から11434番が直接見える必要はない。
1. 11434番ポートへの直接アクセスを遮断する
$ sudo ufw deny 11434/tcp Rule added $ sudo ufw deny 11434/tcp (v6) Rule added (v6)
OLLAMA_HOST=127.0.0.1 でlocalhostバインドに変更済みなら実質的に外部から11434番には届かない。それでも明示的にUFWで遮断しておくことで、環境変数の設定ミスやサービス再起動後の一時的な設定ずれを防ぐ二重の保護になる。
2. HTTPSポートと必要なルールを整理する
$ sudo ufw allow 'Nginx HTTPS' $ sudo ufw reload $ sudo ufw status Status: active To Action From -- ------ ---- Nginx HTTP ALLOW Anywhere Nginx HTTPS ALLOW Anywhere 11434/tcp DENY Anywhere Nginx HTTP (v6) ALLOW Anywhere (v6) Nginx HTTPS (v6) ALLOW Anywhere (v6) 11434/tcp (v6) DENY Anywhere (v6)
Nginx HTTP も開けておく。HTTPS専用にしたい場合はHTTP接続をNginxでHTTPSにリダイレクトしつつ、UFWで80番を開けたままにする構成が現実的だ。社内特定サブネット（例: 192.168.10.0/24）からのみ許可したい場合は、
sudo ufw allow from 192.168.10.0/24 to any port 443 で送信元IPを絞り込める。ゼロトラスト的な考え方を取り入れたいチームにはこの設定が適している。
よくあるトラブルと対処法
設定後に詰まりやすいポイントをまとめる。 502 Bad Gatewayが返ってくるNginxからOllamaへのプロキシが失敗している。まず
sudo systemctl status ollama でOllamaが起動しているか確認する。次に
sudo ss -tlnp | grep 11434 でバインドアドレスが 127.0.0.1:11434 になっているかチェックする。0.0.0.0:11434 のままならoverride.confの反映に失敗しているため、sudo systemctl daemon-reload && sudo systemctl restart ollama を再実行する。certbotが失敗してドメイン認証エラーになる
Let's Encryptはポート80番への外部アクセスで認証する。UFWで80番が閉じていないか、DNS AレコードがサーバーIPを正しく向いているかを確認する。
CloudflareなどのCDN経由の場合はオレンジ雲（プロキシ有効）をオフにして一時的にDNS直接向きにしてから取得する。
Basic認証ダイアログが表示されない
auth_basic の設定が反映されていない可能性がある。sudo nginx -t で構文エラーを確認し、sudo systemctl reload nginx を実行する。また
/etc/nginx/.htpasswd のパーミッションが www-data（Nginxの実行ユーザー）に読み取り可能か sudo chmod 640 /etc/nginx/.htpasswd && sudo chown root:www-data /etc/nginx/.htpasswd で調整する。LLMのストリーミング応答が途中で切れる
proxy_read_timeout が不足している。Llama3.3の70Bクラスはq4_0量子化（llama3.3:70b-instruct-q4_0）でも応答生成に数分かかることがある。proxy_read_timeout 600s; まで引き上げると改善するケースが多い。curlでAPIを叩くと401 Unauthorizedが返ってくる
Basic認証が有効なため
-u オプションが必要だ。curl -u llmuser01:password https://ollama.example.com/api/tags の形で認証情報を渡す。PythonクライアントやOpen WebUIでは接続URLに https://llmuser01:password@ollama.example.com と埋め込む方法もある。モデルの量子化や推論速度の選択については、ローカルLLMのモデルを比較する方法｜Llama3.3・Mistral・Gemma・Phi-4をUbuntuで使い分けるポイントが参考になる。用途別のモデル選定まで詳しく解説している。
まとめ
OllamaをNginxリバースプロキシで安全に公開するための設定を一通り解説した。各手順のコマンドと役割を以下の表にまとめる。| 手順 | コマンド・設定ファイル | 役割 |
|---|---|---|
| Ollamaバインド制限 | OLLAMA_HOST=127.0.0.1（override.conf） | 外部への直接バインドを遮断する |
| Nginxインストール | sudo apt install nginx -y | リバースプロキシのベースを用意する |
| プロキシ設定 | proxy_pass http://127.0.0.1:11434; | Ollamaへリクエストを転送する |
| HTTPS化 | sudo certbot --nginx -d ドメイン名 | 通信の暗号化と証明書の自動更新を設定する |
| Basic認証 | sudo htpasswd -c /etc/nginx/.htpasswd ユーザー名 | ユーザー名/PW認証で不正アクセスを防ぐ |
| UFWポート制御 | sudo ufw deny 11434/tcp | 直接アクセスの最終的な遮断層にする |
これらを積み重ねることで「Nginxが入口・Basic認証が門番・UFWが外壁」という多層防御が完成する。一つの設定ミスがあっても他の層が補う設計だ。
ローカルLLMの構築がまだの段階から読み直したい場合は、Ubuntu ServerでローカルLLMを構築する方法｜Ollamaで機密データを外に出さず業務AIを動かす完全ガイドを参照してほしい。環境構築から本記事の設定まで一本の流れで理解できる。
ローカルLLMのセキュア構成を2日間のハンズオンで体験する
Nginx・HTTPS・Basic認証の設定を実機で手を動かしながら習得したい方向けに、「ローカルAIマスターセミナー」を開催しています。
少人数（最大8名）ZOOMハンズオン形式で実施しています。
・Ubuntu ServerでローカルLLMを構築する方法｜Ollamaで機密データを外に出さず業務AIを動かす完全ガイド
・社内でChatGPTが使えないときの代替手段｜機密データを守るローカルLLMという選択肢
・ローカルLLMのモデルを比較する方法｜Llama3.3・Mistral・Gemma・Phi-4をUbuntuで使い分けるポイント
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 前のページへ：OllamaをDockerコンテナで運用する方法｜docker-compose.ymlとGPU設定で本番環境に安定デプロイする
- この記事の属するカテゴリ：ローカルLLMへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます