「nginxでリバースプロキシを組もうとしたが、Basic認証やHTTPS化の設定で手が止まっている」
そんな悩みを持つLinuxサーバー管理者は少なくないはずです。この記事では、Ubuntu Server上で稼働中のOllamaをnginxリバースプロキシ配下に置き、Basic認証・HTTPS・レートリミットを加えて安全にチーム公開する手順を解説します。
追加ミドルウェアは不要で、nginx単体で完結します。実機で動作確認済みのコマンドのみを掲載しています。
この記事のポイント
・OllamaはデフォルトでTCP 11434を開放しており、OLLAMA_HOST=0.0.0.0にした瞬間に無認証APIが露出する
・nginxリバースプロキシ＋htpasswdでBasic認証を追加し、チームIDのみアクセス可能にする
・Let's EncryptでHTTPS化してBasic認証の平文漏洩リスクを排除する
・limit_req_zoneでレートリミットを設定し、GPU過負荷とブルートフォースを防ぐ
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
なぜOllamaのAPIを認証なしで公開してはいけないか
OllamaはデフォルトでTCP 11434をlocalhost（127.0.0.1）にバインドします。チームサーバーとして共用する際にOLLAMA_HOST=0.0.0.0:11434を設定した瞬間、認証なしのAPIがネットワーク上に丸ごと露出します。具体的なリスクは次の通りです。 ・誰でもモデルのダウンロードAPIを叩けるため、ストレージとGPU帯域を外部に消費される
・
/api/generateを無制限に叩かれてGPUが占有され、本来の業務用途が使えなくなる・VPN内専用にしても、内部からの誤操作や不正利用は防げない
nginxでBasic認証とレートリミットを加えるだけで、これらのリスクのほとんどは軽減できます。設定自体は30分以内で終わります。
なお、Ollamaのインストール自体がまだの場合は、先にUbuntu ServerでローカルLLMを構築する方法を参照してOllamaをsystemdサービスとして稼働させてください。本記事はその構成が前提です。
前提環境と全体構成を確認する
動作確認した環境は次の通りです。 ・Ubuntu Server 24.04 LTS・Ollama v0.4以降（systemdサービスとして稼働中）
・nginx 1.24以降
・apache2-utils（htpasswdコマンド用）
・Certbot（Let's Encrypt・HTTPSが必要な場合のみ）
全体の通信経路はこうなります。クライアント → nginx（ポート443 HTTPS・Basic認証・レートリミット）→ Ollama（localhost:11434）。
Ollamaはlocalhostにのみバインドし、外部から直接アクセスさせません。nginxがファイアウォールの内側でセキュリティポリシーを一元管理する構成です。ドメインが用意できない環境でも、HTTPS化の手順だけ省けば他の設定は全て動作します。
nginxをインストールしてリバースプロキシを設定する
1. nginxをインストールする
# nginxとhtpasswdをインストールして起動する sudo apt update sudo apt install -y nginx apache2-utils sudo systemctl enable --now nginx sudo ufw allow 'Nginx Full'
2. Ollamaをlocalhostのみにバインドする
# systemdのoverride設定を開く sudo systemctl edit ollama
[Service] Environment="OLLAMA_HOST=127.0.0.1:11434"
sudo systemctl daemon-reload && sudo systemctl restart ollama # バインド先を確認する（127.0.0.1:11434 が表示されればOK） ss -tlnp | grep 11434
3. nginxのリバースプロキシ設定を作成する
/etc/nginx/sites-available/ollamaを作成します。
server { listen 80; server_name your-domain.example.com; location / { proxy_pass http://127.0.0.1:11434; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_read_timeout 300s; proxy_send_timeout 300s; } }
proxy_read_timeoutは大型モデルの推論時間を考慮して300秒にしています。
sudo ln -s /etc/nginx/sites-available/ollama /etc/nginx/sites-enabled/ sudo nginx -t && sudo systemctl reload nginx # 疎通確認（{"models":[...]} が返ればOK） curl http://your-domain.example.com/api/tags
Basic認証を追加してAPIへのアクセスを制限する
1. パスワードファイルを作成する
# 初回は -c フラグを付ける（2人目以降は -c を外す） sudo htpasswd -c /etc/nginx/.htpasswd ollama-user # パスワードを2回入力する # ファイルを確認する cat /etc/nginx/.htpasswd # ollama-user:$apr1$xxxxx...
2. nginx設定にBasic認証を追加する
/etc/nginx/sites-available/ollamaのlocationブロックに2行追加します。
location / { auth_basic "Ollama API"; auth_basic_user_file /etc/nginx/.htpasswd; proxy_pass http://127.0.0.1:11434; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_read_timeout 300s; proxy_send_timeout 300s; }
sudo nginx -t && sudo systemctl reload nginx # 認証なしで401が返ることを確認する curl -v http://your-domain.example.com/api/tags 2>&1 | grep "< HTTP" # < HTTP/1.1 401 Unauthorized # 認証ありで200・モデル一覧が返ることを確認する curl -u ollama-user:yourpassword http://your-domain.example.com/api/tags
host="http://ollama-user:yourpassword@your-domain.example.com"のようにURLに認証情報を含めるか、HTTPヘッダーでAuthorization: Basic ...を付与します。ユーザーを追加・削除する際は
sudo htpasswd /etc/nginx/.htpasswd usernameで追加、sudo htpasswd -D /etc/nginx/.htpasswd usernameで削除できます。メンバーの入れ替わりがある現場でも管理が簡単です。パスワードファイルへの変更はnginxの再起動なしで即時反映されます。チームでのモデル選定については、ローカルLLMのモデルを比較する方法も参照してください。Llama3.3・Mistral・Gemma 3・Phi-4の使い分けを解説しています。
Let's EncryptでHTTPS化してBasic認証を暗号化する
【注意】Basic認証はHTTPのまま使うと認証情報が平文で流れます。VPN内専用でも盗聴リスクを排除するためにHTTPS化を強く推奨します。Let's EncryptはDV（ドメイン認証）証明書を無料で発行するサービスです。CertbotはLet's Encryptの公式クライアントで、nginxプラグインを使うと設定ファイルの書き換えと証明書の取得を1コマンドで完了できます。証明書の有効期間は90日ですが、Certbotが自動更新するため手動作業は不要です。VPS・クラウドインスタンスのパブリックIPにAレコードを向けたドメインが取得済みであれば、以下の手順で10分以内に完了します。
sudo apt install -y certbot python3-certbot-nginx # nginxプラグインで証明書を取得・nginx設定を自動更新する sudo certbot --nginx -d your-domain.example.com # "Congratulations!" が表示されれば成功 # 自動更新の動作確認（実際の更新は走らない） sudo certbot renew --dry-run
certbot renew --dry-runが成功すれば証明書の有効期限切れを心配する必要はありません。HTTPS化後、
curl https://your-domain.example.com/api/tags -u ollama-user:yourpasswordで200とモデル一覧が返ることを確認します。情シス担当者向けのローカルLLM導入判断については、社内でChatGPTが使えないときの代替手段で整理しています。セキュリティ要件の整理にも役立ちます。
レートリミットを設定してGPU過負荷とブルートフォースを防ぐ
Basic認証があっても、認証済みユーザーが高頻度にリクエストを送ればGPUを占有されます。nginxのlimit_req_zoneで対処します。/etc/nginx/nginx.confのhttp {}ブロック内に以下を追加します。
# /etc/nginx/nginx.conf の http {} ブロック内に追記する limit_req_zone $binary_remote_addr zone=ollama_api:10m rate=6r/m;
rate=6r/mは1分あたり6リクエスト（約10秒に1回）です。Llama3.3のような大型モデルで1リクエストあたり10～30秒かかることを考えると実運用に合った数値です。次に
/etc/nginx/sites-available/ollamaのlocationブロックで適用します。
location / { limit_req zone=ollama_api burst=3 nodelay; auth_basic "Ollama API"; auth_basic_user_file /etc/nginx/.htpasswd; proxy_pass http://127.0.0.1:11434; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_read_timeout 300s; proxy_send_timeout 300s; }
burst=3はバーストを3リクエストまで許容し、4リクエスト目から503を返します。チームの人数や用途によってrateとburstは調整が必要です。nodelayオプションはバーストリクエストを遅延なく処理します。これを外すと、バースト内のリクエストは均等な間隔に引き伸ばされて処理されます。チャット系の用途ではnoddelayあり、バッチ処理系はnoddelayなしで均等化する運用が向いています。
sudo nginx -t && sudo systemctl reload nginx # レートリミットが発動するとerror.logに記録される tail -f /var/log/nginx/error.log # 2026/09/19 10:00:01 [error] limiting requests, excess: ...
設定後のよくあるトラブルと対処法
設定変更後に遭遇しやすい問題をまとめます。1. 設定後に502 Bad Gatewayが返る
Ollamaのsystemdサービスが停止しているケースが大半です。sudo systemctl status ollama sudo journalctl -u ollama -n 30 --no-pager # 停止していれば起動する sudo systemctl start ollama
2. パスワードが正しいのに401になる
htpasswdファイルのパーミッション不足が原因のことがあります。nginx workerプロセス（www-data）が読めるようにします。デフォルトで644になっているはずですが、sudoなしで作成した場合に600（オーナーのみ読み取り可）になっていることがあります。
sudo chmod 644 /etc/nginx/.htpasswd sudo systemctl reload nginx
3. 正規ユーザーが503になる
burstの値が小さすぎるか、rateが用途に対して厳しすぎるケースです。知人のインフラエンジニアから聞いた話では、RAGパイプラインのリトライロジックが短時間で10リクエスト以上を送出し、チーム全員が503を受けたことがあったそうです。rate=10r/m burst=5に緩和して対処したとのことです。
まとめ
OllamaのAPIをnginxで保護する手順をまとめます。| 設定内容 | 主なコマンド・設定 | 効果 |
|---|---|---|
| localhostバインド | OLLAMA_HOST=127.0.0.1:11434（systemd override） |
外部からOllamaへの直接アクセスを遮断 |
| リバースプロキシ | proxy_pass http://127.0.0.1:11434;（nginx設定） |
全リクエストをnginx経由に統一 |
| Basic認証 | sudo htpasswd -c /etc/nginx/.htpasswd user |
認証済みユーザーのみAPIを利用可能に |
| HTTPS化 | sudo certbot --nginx -d domain |
Basic認証の平文漏洩リスクを排除 |
| レートリミット | limit_req_zone rate=6r/m burst=3 |
GPU過負荷・ブルートフォースを緩和 |
nginxはHTTPSターミネーション・Basic認証・レートリミットを1台で担えるため、Ollamaのようなシングルホスト運用には特に相性が良いです。IPホワイトリスト（
allow/denyディレクティブ）を組み合わせれば、接続元IPを固定しながらBasic認証を使うという2段構えも簡単に実現できます。20年以上Linuxサーバーを触ってきた感覚では、「とりあえず動いたから認証は後で」という現場ほど後から設定を入れるコストが高くなっています。初期構築のタイミングでnginxのセキュリティレイヤーを入れておくのが結局一番楽です。
ローカルLLMのセキュア運用を2日間のハンズオンで体験する
nginx認証・HTTPS・レートリミットを実機GPU環境で設定しながら習得したい方向けに、「ローカルAIマスターセミナー」を開催しています。
少人数（最大8名）ZOOMハンズオン形式で実施しています。
・Ubuntu ServerでローカルLLMを構築する方法｜Ollamaで機密データを外に出さず業務AIを動かす完全ガイド
・社内でChatGPTが使えないときの代替手段｜機密データを守るローカルLLMという選択肢
・ローカルLLMのモデルを比較する方法｜Llama3.3・Mistral・Gemma・Phi-4をUbuntuで使い分けるポイント
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 前のページへ：OllamaとQdrantでローカルベクター検索を構築する方法｜Rustベース高性能ベクターDBをUbuntuに導入してRAGを高速化する手順
- この記事の属するカテゴリ：ローカルLLMへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます