トラブルシューティング

まず、ブラウザー、フロントエンド、バックエンド、Ollama、プロバイダープラグイン、デプロイのネットワークのうち、どの層で問題が発生しているかを特定します。

クイックチェック

# App branch and local changes
git status

# Backend process liveness
curl http://localhost:3001/health/live

# Backend dependency readiness (SQLite, schema, and writable data storage)
curl http://localhost:3001/health/ready

# Ollama health
curl http://localhost:11434/api/tags

# Installed Ollama models
ollama list

開発環境では通常、フロントエンドは http://localhost:5173、バックエンドは http://localhost:3001 で動作します。パッケージ版の npx libre-webui フローでは、アプリは http://localhost:8080 で提供されます。

Libre WebUI が起動しない

Node と依存関係を確認する

node --version
npm install
npm run dev

Node.js 22.22 以降が必要です。

ポートがすでに使用されている

lsof -i :3001
lsof -i :5173
lsof -i :8080

古いプロセスを停止するか、別のポートを設定してください。

バックエンドがデータを書き込めない

DATA_DIR が設定されている場合、バックエンドはその配下にデータを保存します。設定されていない場合は backend/data に保存します。ソースから起動するとき、相対 DATA_DIR はシェルの現在のディレクトリではなく、バックエンドディレクトリを基準に解決されます。そのため、 DATA_DIR=./data は backend/data を選択し、歴史的に対応している DATA_DIR=./backend/data は backend/backend/data を選択します。選択されたディレクトリが書き込み可能であることを確認してください。DATA_DIR が未設定の場合、 Libre は従来のディレクトリが唯一存在するストアであれば、それを維持します。両方の場所にデータがある場合は Libre を停止し、両方をバックアップしてから、どちらを使用するか、またはどのように移行するかを意図的に決めてください。Libre が異なるデータベースをマージまたはコピーすることはありません。

ヘルスエンドポイントは、プロセスが実行中であることと、アプリケーションが使用可能であることを意図的に区別します。

/health と /health/live は、バックエンドプロセスが HTTP を提供できる間は 200 を返します。任意のモデルプロバイダーは liveness に影響しません。
/health/ready は、必須のデータベース、スキーマ、ストレージ、または登録済みプラットフォーム依存関係を利用できない場合に 503 を返します。任意のモデルプロバイダーを待機しません。公開応答では、エラーメッセージと内部詳細が省略されます。
/health/deep は上限付きワーカー内で SQLite の整合性および外部キーを確認し、Ollama などの任意のサーバーレベルプロバイダープローブを集約します。任意のプロバイダー停止は警告として表示され、必須の依存関係を unready にはしません。このエンドポイントには現在有効な管理者の bearer token が必要で、頻繁なオーケストレータープローブには適していません。

curl -H "Authorization: Bearer $LIBRE_ADMIN_TOKEN" \
  http://localhost:3001/health/deep

ブラウザーからバックエンドに接続できない

ローカル開発では、フロントエンドは VITE_API_BASE_URL が設定されていればそれを使用し、設定されていなければ開発用バックエンドへフォールバックします。

フロントエンドの .env 例：

VITE_API_BASE_URL=http://localhost:3001/api
VITE_WS_BASE_URL=ws://localhost:3001

VITE_WS_BASE_URL は任意ですが、設定すると Chat と Work のターミナルソケットで共有するベースになります。絶対 ws: または wss: URL を使用してください。 wss://example.com/libre のようなパスプレフィックスにも対応しています。資格情報、クエリパラメーター、フラグメントは含めないでください。Vite 変数を変更した後は、フロントエンドを再起動または再ビルドします。

バックエンドの .env 例：

CORS_ORIGIN=http://localhost:5173,http://127.0.0.1:5173

スマートフォン、LAN、Tailscale からアクセスする場合、スマートフォンのブラウザーで localhost を指定しないでください。ノート PC の LAN または Tailscale IP を使用し、ホストバインドを有効にして開発サーバーを実行します。

npm run dev:host

これはフロントエンドをポート 8080 で提供し、API と WebSocket のトラフィックをローカルのポート 3001 で動作するバックエンドにプロキシします。他の端末から到達可能である必要があるのはポート 8080 だけです。frontend/.env で VITE_API_BASE_URL または VITE_WS_BASE_URL が設定されている場合は、それらの URL が他の端末から到達可能であることを確認するか、削除して開発サーバーのプロキシを使用してください。

リバースプロキシ経由で Chat がストリーミングされない

典型的な症状は、メッセージを送信できても応答がまったく描画されず、ブラウザーコンソールに WebSocket 接続エラーが表示されることです。プロキシが WebSocket アップグレードを許可し、長時間の接続を閉じないことを確認してください。

いずれかの値が設定されている場合、Origin ヘッダーを送るブラウザーアップグレードは CORS_ORIGIN と BASE_URL に照らして確認されます。リモートデプロイでは少なくとも一方を設定してください。どちらも未設定なら、ローカル開発向けに Origin フィルターは寛容なままです。 Electron などブラウザー以外のクライアントは Origin を省略する場合がありますが、それでも最初に Authorization ヘッダーを短時間有効な 1 回限りのチケットへ交換する必要があります。バックエンドは TLS の背後に置き、HTTP API と同じネットワークまたはリバースプロキシのアクセス制御を適用してください。

公開ホスト名を使用する場合は、Libre WebUI サービスでそのブラウザーオリジンを許可します。

services:
  libre-webui:
    environment:
      CORS_ORIGIN: https://chat.example.com
      BASE_URL: https://chat.example.com

以下の nginx および Caddy の例では、プロキシが Docker ホスト上で動作し、リポジトリの Compose 設定が Libre WebUI をポート 8080 で公開しているものとします。プロキシを Compose ネットワークに参加させる場合は、上流アドレスに libre-webui:3001 を使用してください。

nginx

nginx では、アップグレードヘッダーを明示的に転送する必要があります。長い読み取りタイムアウトにより、モデルが処理している間、一時的にアイドル状態になる Chat 接続を開いたままにできます。

location /ws {
    proxy_pass http://127.0.0.1:8080;
    proxy_http_version 1.1;
    proxy_set_header Host $host;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_read_timeout 3600s;
}

nginx -t で設定を検証してから nginx を再読み込みします。

Caddy

Caddy の reverse_proxy はそのまま WebSocket に対応するため、アップグレードヘッダーは不要です。

chat.example.com {
    reverse_proxy 127.0.0.1:8080
}

Traefik

Traefik もデフォルトで WebSocket アップグレードを処理します。Docker プロバイダーが Libre WebUI のネットワークを共有する場合は、通常のルーターとサービスラベルだけで済みます。例：

labels:
  - 'traefik.enable=true'
  - 'traefik.http.routers.libre-webui.rule=Host(`chat.example.com`)'
  - 'traefik.http.routers.libre-webui.entrypoints=websecure'
  - 'traefik.http.routers.libre-webui.tls=true'
  - 'traefik.http.services.libre-webui.loadbalancer.server.port=3001'

ストリームに接続できても後で切断される場合は、Traefik の前段にあるプロキシまたはロードバランサーのアイドルタイムアウトを確認してください。Traefik 自体が制限を適用している場合は、エントリーポイントの transport.respondingTimeouts 設定を調整します。

Ollama が検出されない

Ollama が実行中か確認する

curl http://localhost:11434/api/tags

カスタム Ollama URL を設定する

バックエンドの .env：

OLLAMA_BASE_URL=http://localhost:11434

Libre WebUI を Docker で実行し、Ollama をホストで実行している場合は、外部 Ollama 用の Compose ファイルを使用するか、コンテナから到達できるホストアドレスを OLLAMA_BASE_URL に指定してください。

モデル取得の問題

まずターミナルから取得する

ollama pull gemma4:12b

ターミナルからの取得に失敗する場合、問題は Libre WebUI の外部にあります。

クラウドモデル

Ollama Cloud モデルには、モデルマネージャーのクラウドフィルターを使用します。このフローでは Libre WebUI が必要なクラウドサフィックスを正規化するため、対応するクラウド項目にユーザーが :cloud を手動で追加する必要はありません。

ユーザーがモデルを取得できない

管理者は、一般ユーザーによるモデル取得を無効にできます。管理者以外のユーザーがモデルを参照できてもインストールできない場合は、管理者設定を確認してください。

Chat が遅い、または失敗する

より小さなモデルを使用します。
ollama ps で読み込み済みモデルを確認します。
コンテキスト長を減らします。
非常に長い応答では最大トークン数を減らします。
モデルが RAM/VRAM に収まることを確認します。
プロバイダープラグインでは、API キーとプロバイダーの割り当て上限を確認します。

OpenAI の画像生成を利用できない

同梱の OpenAI プロバイダーを有効にします。現在のユーザー用に API キーを保存するか、信頼済みの組み込みプロバイダーで OPENAI_API_KEY 環境変数のフォールバックを設定します。
画像生成設定を開いて画像生成を有効にし、表示されている GPT Image モデルの 1 つを選択します。
gpt-image-2 を推奨します。古い GPT Image ID は既存設定との互換性のためだけに残されており、上流では非推奨です。
互換性のある画像エンドポイントを運用している場合を除き、OpenAI の image_endpoint 上書きは空のままにします。Chat の /responses または /chat/completions エンドポイントでは、 Image API リクエストを処理できません。
有効なキーと割り当て上限があるにもかかわらず OpenAI が GPT Image リクエストを拒否する場合は、 API 組織が GPT Image モデルを使用できることを確認します。

画像の可用性は、現在のユーザーが保存した資格情報、または信頼済みの組み込みプロバイダーの環境変数フォールバックで評価されます。別のユーザーの設定にだけ保存されたキーでは、画像モデルは公開されません。

プロバイダーエンドポイントの問題

OpenAI 互換プロバイダーが誤ったパスでリクエストを受け取る場合は、 設定 → プラグインでその設定を確認します。

/chat/completions ペイロードには Chat Completions、/responses ペイロードには Responses を選択します。
ベース URL には、https://provider.example/v1 のような API ルートを入力します。
モードのデフォルトを使用するには API パスを空にします。別のパスを使う場合は、プロバイダーが指定する先頭がスラッシュのパスを入力します。
実際のカスタム従来型完全エンドポイントは意図的に最優先されるため、ベース URL と API パスへ戻すときは消去してください。単に組み込みマニフェストの古いデフォルトと同じ保存値は、アップグレード後に自動的に無視されます。カスタムエンドポイントが /chat/completions または /responses で終わる場合、そのサフィックスによってリクエスト形式も決まるため、上書き先へ誤ったペイロードが送られることはありません。

インポートしたプラグイン JSON は、OpenAI Chat Completions、OpenAI Responses、Anthropic、 Gemini 互換のいずれかの通信形式を使うプロバイダーに対応します。プロバイダーが独自のペイロード、ストリーミングイベント、ツール呼び出し、または応答形式を使う場合はバックエンドアダプターが必要です。エンドポイントを変更するだけでは変換できません。

プロバイダー URL では HTTP または HTTPS を使用できます。HTTP では資格情報とプロバイダー通信がトランスポート暗号化なしで送信されるため、信頼できるネットワーク上のセルフホスト型ゲートウェイに限定し、TLS を利用できる場合は常に HTTPS を推奨します。ベース URL にクエリ文字列またはフラグメントを含めることはできず、相対 API パスにリテラルまたは繰り返しエンコードされたトラバーサルセグメント、クエリ文字列、フラグメントを含めることもできません。検証の上限内で安定しない過剰なエンコードは拒否されます。

モデル更新では、/responses など既知の操作サフィックスを /models に置き換えます。有効化、明示的な更新、保存済み接続の上書きには、現在のユーザーのエンドポイントと API キーが使用されます。そのユーザーの API キーを保存または削除した場合や、接続上書きをリセットした場合も一覧が更新されます。無関係な生成パラメーターでは更新されません。検出された ID はユーザーごとに保存され、共有プラグイン JSON を上書きすることはありません。導出されたルートにプロバイダーが対応していない場合は、プラグインの model_map にモデル ID を手動で設定します。

モデル検索、Chat、Work、画像生成、埋め込み、テキスト読み上げを含め、プロバイダーリクエストは意図的に HTTP リダイレクトに従いません。リダイレクトする URL ではなく最終宛先 URL を設定してください。このフェイルクローズ動作により、Authorization ヘッダーが検証されていない宛先へ移動するのを防ぎます。

実行中に Work がプロバイダールーティングの変更を報告した場合は、プロバイダー設定の更新を完了してから新しい実行を開始してください。以前のツール状態が別のモード、エンドポイント、または API キー認証境界へ再生されないよう、Work は次のプロバイダーリクエストの前に意図的に停止します。

リクエストはバックエンドから送信されるため、バックエンドがコンテナ内で動作している場合、localhost はホストマシンではなく Libre WebUI コンテナを指します。Compose または Kubernetes デプロイでは、 http://ai-gateway:8080/v1 のようなゲートウェイのサービス DNS 名を使用してください。 http://host.docker.internal:8080/v1 は、コンテナランタイムがそのホスト別名を公開している場合だけ使用します。名前がプライベートに解決されても、HTTP 通信は平文です。

画像モデルの可用性、エンドポイントの上書き、API キーも現在のユーザーについて解決されます。画像リクエストが別アカウントのプロバイダー設定を使っているように見える場合は、期待するユーザーとしてリクエストが認証されているか確認してください。

次のセキュリティおよび所有権の規則も適用されます。

プロバイダールーティングを変更するには、管理者としてサインインします。プラグイン定義と接続フィールドはインスタンス管理の設定です。一般ユーザーも生成設定、資格情報、自分の有効化状態を保存できます。
従来の endpoint または api_url 上書きを使用する場合は、操作パスを含む完全な API エンドポイント URL を入力します（例：https://provider.example/v1/chat/completions）。 API ルートは base_url にだけ入力し、api_mode と任意の api_path を組み合わせます。
HTTP および HTTPS の絶対エンドポイント URL が受け入れられます。HTTP では API キー、プロンプト、応答がトランスポート暗号化なしで送られるため、信頼できるネットワーク上のセルフホスト型ゲートウェイに限って使用してください。
空の上書きでは、プラグイン定義に含まれるエンドポイントが使用されます。不正または安全でない上書きを明示すると拒否され、Libre WebUI が暗黙に組み込みプロバイダーエンドポイントへリクエストを送ることはありません。
デプロイ環境のキーが使用されるのは、シャドウされていない組み込み定義が、信頼済みルートエンドポイント、認証フィールド、機能エンドポイントとセレクター、ルーティング変数のデフォルトを維持している場合だけです。インポートした定義、組み込み ID を再利用する書き込み可能な定義、管理者が保存したカスタムルートには、同じアカウントで保存した資格情報が必要です。環境変数のキーしか存在しない場合、Libre WebUI は意図的にプロバイダーを利用不可として報告し、検索をスキップします。
以前のリリースでは管理者の出所が記録されていなかったため、アップグレード前のカスタム定義は隔離されます。管理者として JSON を再インポートし、その後各ユーザーがもう一度有効にしてください。承認済みのプラグイン JSON を直接編集すると再び隔離されます。ソースパスと定義ハッシュが記録されるよう、管理者用のインストールまたは更新フローを使用してください。
保存した資格情報は、入力時に有効だったルート、認証コントラクト、定義、ソースへ結び付けられます。エンドポイントまたは定義を変更した後は、そのアカウントの資格情報を再保存してください。バインドのない古い資格情報が自動移行されるのは、アンカー済みの組み込みルートと完全に一致する場合だけです。
インポートしたプラグインでは、従来の完全操作 URL の別名として api_url を使用できます。両方のフィールドが設定されている場合は endpoint が優先されます。モデル検索先が別にある場合は、完全なモデル一覧 URL を models_endpoint に設定します。この URL は検証され、リダイレクトには従いません。
エンドポイントと資格情報を保存した後にプラグインを有効にします。有効化では保存済みの完全なエンドポイントから /models URL を導出し、models_endpoint が設定されていない限り、有効化したユーザーの資格情報で検索します。これらの接続フィールドを保存またはリセットした場合も検索が更新されます。UI がプラグイン一覧を再読み込みする前に、検索の完了を待ちます。有効化はアカウント単位なので、別のユーザーは同じ共有プラグインを個別に有効にする必要があります。
設定 → プラグインでプロバイダーを選び、モデルを更新を選択して、カタログを明示的に確認します。モデル表は読み取り専用で、現在のアカウント用に設定または検索された ID を表示します。一時的な検索失敗では以前の検索済みカタログが維持されます。以前の結果がなければプラグインのフォールバック model_map が使われるため、確認の完了だけではリモートエンドポイントが正常であることを証明できません。
自動検索には、モデル ID を含む OpenAI 互換の data 配列が必要です。成功したカタログは共有プラグイン JSON を変更せず、ユーザーごとに保存されます。通常の有効化では、検索を利用できない場合もユーザーの以前のカタログが維持されます。接続フィールドを変更またはリセットすると古いカタログが先に消去されるため、更新に失敗した場合はプラグインの既存の model_map が使われます。必要なときは、フォールバック用モデル ID をプラグイン JSON に設定してください。
画像モデルの可用性、エンドポイントの上書き、API キーも現在のユーザーについて解決されます。画像リクエストが別アカウントのプロバイダー設定を使っているように見える場合は、期待するユーザーとしてリクエストが認証されているか確認してください。
アップグレードした管理者以外のアカウントにルーティング値が保存されていた場合は、そのプラグインで リセットを実行します。無視されている従来値が消去され、後のロール変更後に有効になることを防ぎます。ルーティングを保存またはリセットすると、そのアカウントが検索したモデルも消去されるため、古いカタログが以前のルートを引き継ぐことはありません。
リクエストはバックエンドから送信されます。Libre WebUI がコンテナ内で動作している場合、 localhost はそのコンテナを指し、ホストマシンを自動的に指すことはありません。
プロバイダーリクエストはリダイレクトに従いません。検証済みの最終操作 URL を直接設定してください。

Chat が誤ったプロバイダーを使用する、またはプロバイダーを利用不可と表示する

同じモデル ID が Ollama と複数のプラグインに存在することがあります。現在の Chat セッションとデフォルトモデル設定では、生のモデル ID に加えて選択したプロバイダーも保存されるため、名前が似た項目も独立した選択肢です。

選択画面にプロバイダーが利用不可と表示された場合は、そのプラグインを再有効化または再インストールし、モデルマップに保存済みのモデル ID が引き続き含まれていることを確認します。
プロバイダーまたはモデルを意図的に削除した場合は、代わりの項目を明示的に選択してください。 Libre WebUI は、保存済みの厳密な選択を、別プロバイダーの同名モデルへリダイレクトしません。
古いセッションと設定にはプロバイダーメタデータがない場合があります。どのプロバイダーを意図していたか Libre WebUI が推測できないため、これらのレコードは従来の名前だけによるルーティングを使い続けます。モデル選択画面では「プロバイダー未記録」と表示されます。使用する Ollama またはプラグイン項目を再選択し、以後のリクエストをその項目へ固定してください。
ペルソナ項目のラベルは persona:<id> のままです。新しく選択したペルソナは、基盤プロバイダーとして Ollama を記録します。プロバイダーメタデータがない過去のペルソナセッションは、従来のルーティングとの互換性を維持します。

Work の問題

Work が表示されない、またはランタイムを利用できないと報告される

Work には、現在認証されており Work へのアクセス権があるアカウントが必要です。つまり管理者、または管理者が設定のユーザー管理タブで Work を全ユーザーに公開した後の有効なユーザーです。コンテナランタイムは Libre WebUI バックエンドから利用可能でなければなりません。

docker info
docker version

デフォルトの Docker バックエンドでは、Docker が実行中で、Libre WebUI を実行する OS ユーザーが設定済みの WORK_DOCKER_COMMAND を呼び出せることを確認します。npx で Libre WebUI をインストールしても Docker はインストールされません。ランタイムがない場合、Libre WebUI はアプリの他の部分を利用可能なまま維持し、モデルのコマンドをホスト上で実行する方式へフォールバックしません。

リポジトリの Compose ファイルは、ホストの Docker ソケットをマウントして Work を有効にします。 Kubernetes では Helm 値 work.enabled=true でネイティブの Pod/PVC ランタイムを有効にし、ノードのランタイムソケットはマウントしないでください。Compose デプロイで引き続き ランタイムを利用できませんと表示される場合、Work ページには次のどれに該当するかが表示されます。

メッセージ	原因と解決方法
`The "docker" CLI is not installed…`	`docker-cli` のないカスタムイメージです。公式イメージを使うか、`WORK_DOCKER_COMMAND` で CLI を指定します。
`No Docker daemon is reachable…`	ソケットマウントが削除されたか、ホストデーモンが停止しています。Compose ファイルのマウントを戻して Docker を起動します。
`The Docker socket is mounted but…cannot open`	ソケットのグループがコンテナと異なります。`.env` に `DOCKER_GID` を設定し（下記参照）、コンテナを再作成します。
Work の画面／音声が WebSocket `1006` で切断され、`screen is unreachable` が記録される	コンテナ内のバックエンドが自分自身のループバックへ接続しようとしています。Docker Desktop では同梱の `WORK_DOCKER_PUBLISHED_HOST=host.docker.internal` を使います。ネイティブの Docker Engine ではさらに `WORK_PREVIEW_BIND` を公開されていない Docker ブリッジのゲートウェイに設定し、Libre WebUI を再作成します。

macOS ホストが報告する値はコンテナから見える値と異なるため、コンテナ経由でソケットグループを読み取ります。

echo "DOCKER_GID=$(docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
  alpine stat -c '%g' /var/run/docker.sock)" >> .env
docker compose up -d --force-recreate

このソケットは Docker ホストに対する root 相当の制御を付与します。デプロイへの影響については、 Work：分離ワークスペースを確認してください。

モデルがツールに対応していない

Work にはツール対応のチャットモデルが必要です。Ollama では、報告される機能に tools が含まれるインストール済みモデルを選びます。プラグインを使用するモデルでは、次を確認してください。

チャットまたは補完プラグインが有効である。
選択したモデルが、そのプラグインで設定されたモデル一覧にある。
現在の管理者が API キーを利用できる。
プロバイダーがそのモデルでツール呼び出しに対応している。

Libre WebUI は、失敗した Work 実行を別のプロバイダーへ暗黙にルーティングしません。

Work リクエストが HTTP 429 を返す

インスタンスがタスクまたは有効なランタイムの受付上限に達しています。デフォルトでは、Libre WebUI はインスタンス全体でコンテナを使用する有効なタスクを 2 件、ユーザーごとに 1 件まで許可します。実行中のプレビューもランタイム容量を使用します。他の操作が完了するまで待つ、不要なプレビューを停止する、または運用担当者に WORK_MAX_ACTIVE_RUNTIMES_* と WORK_MAX_TASKS_* の設定を確認してもらってください。

パッケージのインストールまたはネットワークアクセスが失敗する

新しい Work タスクは Docker ブリッジネットワークを使用するため、生成されたプロジェクトはパッケージをダウンロードしてプレビューを起動できます。Docker の DNS、プロキシ設定、レジストリの可用性、 アクティビティのコマンド出力を確認してください。Libre WebUI は、ホストの SSH キー、クラウド資格情報、ブラウザープロファイル、Docker ソケットをタスクコンテナへマウントしません。

Work プレビューが起動しない

サーバーが WORK_PREVIEW_PORT（デフォルトは 4173）の 0.0.0.0 にバインドされていることを確認します。
任意のコマンドを空にすると、package.json の dev スクリプトまたは単純な index.html が自動検出されます。1 階層内側にあるアプリにも対応します。
Work が複数のアプリまたは対応するエントリーポイントがないと報告した場合は、プロジェクト固有の開発コマンドを任意コマンドフィールドに入力します。コマンドは /workspace で始まるため、入れ子のアプリには cd <app-directory> && ... を使用します。
返されたエラーの詳細を展開し、起動時の出力を確認します。
コンテナを必要とする別のコマンドを開始する前に、既存のプレビューを停止します。

プレビュー URL では、動的に割り当てられたループバックポートを使用します。そのため、ブラウザーと Libre WebUI バックエンドは同じマシンで実行する必要があります。リモートバックエンドへ接続したブラウザーからは、そのバックエンドのループバックプレビューへ到達できません。また HTTPS ページでは、平文 HTTP のプレビューが混在コンテンツとしてブロックされる場合があります。

ワークスペースのファイルを開けない、または保存できない

Work のファイル API は、最大 2 MB の UTF-8 テキストファイルを受け入れます。ファイルを開いた後に内容が変更された場合は、新しいバージョンを上書きしないよう、保存前に再読み込みしてください。フォーマットは、100,000 文字および 4,000 行未満の対応ファイル形式に限定されます。大きなファイルでは、編集の応答性を保つため、構文強調表示が一時停止します。

未保存の編集は、現在のブラウザーに下書きとして保持されます。永続ワークスペースへ保存する代わりにはなりません。

タスクまたはプレビューが停止された

実行やプレビューを停止した場合、または Libre WebUI を再起動した場合、使い捨てコンテナのプロセスは停止しますが、タスクの名前付きワークスペースボリュームは維持されます。タスクを再度開き、プレビューを再起動してください。タスクの削除はこれとは異なります。確認後、タスクとそのワークスペースは完全に削除されます。

ログインとサインアップの問題

最初のユーザーが管理者ではない

新しいデータベースで最初に作成したアカウントだけが管理者になります。既存のデータベースでは現在のユーザーとロールが維持されます。

JWT エラー

本番環境では安定したシークレットを設定します。

JWT_SECRET=replace-with-a-long-random-secret

JWT_SECRET を変更すると、既存のセッションは無効になります。

Turnstile によってサインアップがブロックされる

Turnstile は、両方のキーが存在する場合にだけ有効になります。

TURNSTILE_SITE_KEY=...
TURNSTILE_SECRET_KEY=...

サインアップが突然失敗するようになった場合は、サイトキーがドメインと一致し、シークレットキーが有効であることを確認してください。

OAuth のリダイレクトが失敗する

プロバイダーのダッシュボードとバックエンドの .env の両方にコールバック URL を設定します。

BASE_URL=https://your-domain.example
GITHUB_CALLBACK_URL=https://your-domain.example/api/auth/oauth/github/callback
HUGGINGFACE_CALLBACK_URL=https://your-domain.example/api/auth/oauth/huggingface/callback

文書 Chat の問題

Libre WebUI は、最大 10 MB の PDF、Office（DOCX/PPTX/XLSX）、Markdown、HTML、コード、CSV ファイルに対応します。

検索は機能してもセマンティック検索が機能しない場合：

nomic-embed-text などの埋め込みモデルをインストールします。
設定で埋め込みを有効にします。
文書設定または API から埋め込みを再生成します。

ollama pull nomic-embed-text

埋め込みが無効でも、キーワード検索は引き続き機能します。

アーティファクトプレビューの問題

ゲームまたはインタラクティブ HTML では、インライン CSS と JavaScript を含む、完全で自己完結した 1 つの HTML ファイルをモデルに依頼してください。

アーティファクトでキーボード入力が必要な場合：

まずプレビュー内をクリックします。
「開く」ボタンを使用して、独立したブラウザータブで実行します。
応答に含まれていないローカルファイルに依存しないようにします。

Libre WebUI は一般的な index.html、CSS、JavaScript のコードブロックをまとめられますが、自己完結した HTML が最も確実な出力です。

Docker の問題

コンテナから Ollama に接続できない

Ollama が同じ Compose スタックにない場合は、外部 Ollama 用の Compose ファイルを使用します。

docker compose -f docker-compose.external-ollama.yml up -d

データが永続化されない

永続データボリュームをマウントし、必要に応じて DATA_DIR を設定します。DATA_DIR または Docker モードを使用すると、暗号化キーは永続ストレージに保存されます。

ローカルデータをリセットする

まずアプリを停止します。その後、使用中のデータディレクトリをバックアップして削除します。デフォルトでは、開発データは backend/data にあります。

cp -R backend/data backend/data.backup
rm -rf backend/data

バックエンドを再起動し、新しいアカウントを作成します。

解決しない場合

次の情報を添えて Issue を作成してください。

Libre WebUI のバージョンとコミット
インストール方法
オペレーティングシステム
Node.js のバージョン
Ollama のバージョン
Work の問題の場合は Docker のバージョンと docker info の結果
問題発生時のバックエンドログ
ブラウザーコンソールのエラー
使用している正確なモデルまたはプロバイダー
タスクまたはプレビューが失敗した場合の Work のアクティビティ出力

クイックチェック​

Libre WebUI が起動しない​

ブラウザーからバックエンドに接続できない​

リバースプロキシ経由で Chat がストリーミングされない​

nginx​

Caddy​

Traefik​

Ollama が検出されない​

モデル取得の問題​

Chat が遅い、または失敗する​

OpenAI の画像生成を利用できない​

プロバイダーエンドポイントの問題​

Chat が誤ったプロバイダーを使用する、またはプロバイダーを利用不可と表示する​

Work の問題​

Work が表示されない、またはランタイムを利用できないと報告される​

モデルがツールに対応していない​

Work リクエストが HTTP 429 を返す​

パッケージのインストールまたはネットワークアクセスが失敗する​

Work プレビューが起動しない​

ワークスペースのファイルを開けない、または保存できない​

タスクまたはプレビューが停止された​

ログインとサインアップの問題​

文書 Chat の問題​

アーティファクトプレビューの問題​

Docker の問題​

ローカルデータをリセットする​

解決しない場合​