ComfyUIをLAN・外部公開するときの認証設計｜TLSとリバースプロキシ

ComfyUIをLANの外から使うなら、ComfyUI自体は127.0.0.1で待ち受けたまま、認証とTLSを持つリバースプロキシを唯一の入口にします。--listen 0.0.0.0でそのままインターネットに出すのは、認証のないworkflow実行サーバーを公開することと同じです。

情報確認日：2026年8月22日（日本時間）

結論：ComfyUIは閉じたまま、入口はプロキシ1つ

ComfyUIのAPI経路とServer APIの基本はComfyUI APIの使い方、ブラウザとComfyUIの間にNext.jsを置いて接続先を隠す構成はNext.jsの記事、Queueの同時実行数や負荷制御はQueue制御の記事で扱っています。この記事は「ComfyUIそのものにLAN外から到達させる」場合の防御設計に絞り、特定のVPN製品の設定やUI実装は扱いません。

listen設定だけで外部公開しない

ComfyUIの起動オプション--listenは、ソース上のヘルプ文で既定が127.0.0.1、引数なしで指定すると0.0.0.0,::（IPv4・IPv6の全インターフェース）で待ち受けると説明されています。つまり既定では同じマシンからしか接続できず、--listenを付けた瞬間に、そのマシンに到達できるすべての相手から接続できるようになります。

Server APIには認証がありません。POST /promptに到達できる相手は、任意のworkflow JSONを実行できます。workflowの中にはファイルを読み書きするノード、custom nodeが追加した任意の処理が含まれ得るため、「画像を生成されるだけ」では済みません。加えてPOST /upload/imageでファイルを置け、GET /viewで出力を読め、GET /system_statsで環境情報を取れます。

ComfyUIには--tls-keyfile / --tls-certfileでHTTPS化するオプションもありますが、暗号化と認証は別の話です。TLSを付けても、誰でも実行できる状態は変わりません。

脅威モデルを1枚に書く

対策を選ぶ前に、「誰が・どこから・何を」を1枚に書きます。これが決まらないと、Basic認証で足りるのかVPNが要るのかを判断できません。

3列目の「Webアプリの裏側」が最も多いケースで、この場合は公開入口を作らないのが答えです。Next.jsなどのアプリサーバーと同じホストか同じプライベート網にComfyUIを置き、外から来るのはアプリへのHTTPSだけにします。

リバースプロキシで入口を1つにする

人がLAN外からComfyUIのGUIやAPIを使う必要があるなら、ComfyUIは127.0.0.1:8188のまま、前段にリバースプロキシ（Caddy・nginx など）を置きます。プロキシがTLS終端と認証を担当し、通ったリクエストだけをComfyUIに転送します。

[インターネット] ──HTTPS:443──▶ [リバースプロキシ] ──HTTP:8188（localhost）──▶ [ComfyUI --listen 127.0.0.1]
                                   ├ TLS終端
                                   ├ 認証（Basic / OIDC）
                                   ├ パス制限（/prompt, /ws, /view …）
                                   ├ ボディサイズ上限・タイムアウト
                                   └ アクセスログ

Caddyは証明書の自動取得を含むため、個人用途では設定が短く済みます。以下はBasic認証＋転送の最小例です（設定の文法はCaddy公式ドキュメントで現行版を確認してください）。

# Caddyfile（例）
comfy.example.com {
    basic_auth {
        # caddy hash-password で生成したハッシュを置く。平文は書かない
        alice JDJhJDE0JC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
    }
    request_body {
        max_size 20MB
    }
    reverse_proxy 127.0.0.1:8188
}

WebSocket（/ws）はCaddyのreverse_proxyがそのまま通します。nginxを使う場合はUpgradeとConnectionヘッダの転送設定が必要です。どちらでも、プロキシの待ち受けは443だけにし、8188はファイアウォールで外から閉じます。

認証とTLSを用途で選ぶ

認証方式に万能はありません。利用者の数と、個人を識別する必要があるかで決めます。

どの方式でもTLSは前提です。Basic認証はヘッダに資格情報をそのまま載せるため、HTTPで使えば経路上で読めます。証明書はLet’s Encryptなどで取得し、自己署名証明書は「自分の端末にだけ信頼設定を入れる」用途に限ります。

VPN製品の選定や個別設定はこの記事の範囲外です。どれを選んでも「ComfyUI本体は127.0.0.1（VPNならVPN内アドレス）にしか待ち受けない」点は共通です。

外部から入ってくる値を制限する

認証を通った相手が善意でも、入ってくる値は制限します。誤操作や、利用者の端末が乗っ取られた場合の被害を小さくするためです。

プロキシでルートを絞る例です。許可するパス以外は404にします。

# Caddyfile 抜粋（許可パスだけ転送する例）
@allowed path /prompt /history/* /view /ws /queue /interrupt
handle @allowed {
    reverse_proxy 127.0.0.1:8188
}
handle {
    respond 404
}

GUIを使わせる場合は、フロントエンドの静的ファイルや拡張のルートも必要になるため、この絞り込みはAPI専用の入口に向いています。

ログと更新を運用に入れる

公開した後に必要なのは、「誰がいつ何を実行したか」を後から追えることと、脆弱性修正を取り込み続けることです。

ComfyUIのServer APIは互換性の約束がなく、更新でルートやレスポンスが変わり得ます。更新後はプロキシの許可パスと、アプリ側のclient層が動くかを必ず確認します。

再現してほしい確認：LAN限定構成と認証付きプロキシ構成の経路を比べる

2つの構成で、「どのアドレス・ポートが誰から見えるか」を同じ手順で確認し、表に残します。

1. 構成A（LAN限定）：ComfyUIを既定（127.0.0.1）で起動。同じマシンからcurl http://127.0.0.1:8188/system_stats、LAN内の別端末からcurl http://<ホストのLAN IP>:8188/system_statsを実行する
2. 構成B（プロキシ）：構成Aのまま、プロキシを443で起動。別端末からhttps://comfy.example.com/system_statsを認証なし・認証ありで実行する。さらにhttp://<ホストのLAN IP>:8188/が引き続き拒否されることを確認する
3. ホスト上で待ち受け中のソケットを一覧し（macOS/Linuxならlsof -iTCP -sTCP:LISTEN -n -P、Linuxならss -ltnp）、8188が127.0.0.1にだけ束縛されていることを確認する

見るポイントは「構成Bにしても、8188への直接到達は構成Aと同じく拒否されたままか」です。ここが200になっていれば、プロキシを素通りする裏口が開いています。

よくある質問

まとめ

ComfyUIをLAN外から使う設計は、「ComfyUI本体は127.0.0.1のまま、TLSと認証を持つプロキシだけを入口にする」の一点に集約されます。--listenは認証を足す機能ではなく、到達できる相手を増やす機能です。

誰が・どこから・何を実行してよいかを先に書き、Basic・OIDC・VPNを用途で選び、任意のworkflow・パス・巨大ファイルを外から入れさせず、ログと更新とローテーションを運用に組み込んでください。Webアプリの裏側に置くだけなら、公開入口を作らないのが最も安全です。