PaperspaceでComfyUIが立ち上がらなくなった件｜原因調査｜2026/4
ComfyUIをPaperspaceで立ち上げようとしたら、うまくつながらなくなったという事象を経験しました。
一瞬、PaperspaceではComfyUIが使えない仕様になったのかと思いましたがそうではないようです。
原因を特定しましたので、記事として挙げておきます。
この問題は2026/4/3のアップデートされたComfyUIで起きたものです。
この記事では、その関係を初心者から中級者でも追いやすい形で整理します。解決方法については、ここでは言及しません。
GPTなどに投げて修正してもらってください。
何が起きたのか？
ComfyUI を Paperspace 上で立ち上げると
「URL 自体は正しく出ているのに、ブラウザで開くと画面が出ない。」
という現象がおきました。
最初は「TensorBoard 経由の URL 生成が壊れたのか」と思いやすいのですが、実際にはそこが本質ではありませんでした。
本当の原因は、ComfyUI 側の `server.py` に入ったブラウザ向けのセキュリティ変更と、Paperspace のアクセス経路がうまく噛み合わなくなったことです。
この大元はComfyUIのアップデートです。これ以降のComfyUIで発生します(この内容が修正されなければ)。
何が問題だったのか？
先ほど言及したように、今回の不具合は、ComfyUI の PR #13261 `Fix some issue with insecure browsers.` と直接関係しています。
この変更で、`Sec-Fetch-Site` ヘッダーを使った、より厳しいアクセス制御が `server.py` に追加されました。
ローカル環境では妥当な防御のようですが、Paperspace のようにリバースプロキシ経由で UI を公開する環境では、正常な画面表示リクエストまで `cross-site` と判定されてブロックされることがあります。
つまり、今回壊れていたのは URL の生成そのものではなく、ブラウザが ComfyUI に到達したあとに `server.py` がそのアクセスを拒否していた、という点でした。
まず、Paperspace ではどうやって ComfyUI を開いているのか
ちょっと内容を整理しておきます。
ローカルで ComfyUI を使うときは、普通は次のような URL を直接開きます。
`http://127.0.0.1:8188`
一方、Paperspace では notebook の中で動いているサーバーを、そのままブラウザに直接見せるわけではありません。
代わりに、次のような公開 URL を経由してアクセスします。
`https://tensorboard-<notebook-id>.<cluster-id>.paperspacegradient.com`
この URL に届いたアクセスは、Paperspace の側で notebook 内の ComfyUI プロセスへ転送されます。
ここが重要です。
ブラウザの目線では、これは「同じ場所に直接アクセスしている」のではなく、「Paperspace の画面から別の公開 URL に移動している」ように見えます。
そのときブラウザは何を送るのか
こういう画面遷移のとき、ブラウザはリクエストに `Sec-Fetch-Site` というヘッダーを付けることがあります。
今回のログでは、この値が次のようになっていました。
`Sec-Fetch-Site: cross-site`
これは「別オリジンから来たアクセスですよ」という意味合いを持つ情報です。
Paperspace では、最初の UI 起動がちょうどこの形になります。
この問題を解決する際に調査したログで、実際に次のような状況になっていました。
リクエストは `GET /`
`Referer` は `https://console.paperspace.com/`
`Host` は `tensorboard-...paperspacegradient.com`
`Sec-Fetch-Site` は `cross-site`
つまり、Paperspace から ComfyUI を開く最初の画面表示は、ブラウザ上では「cross-site な document navigation」に見えていたわけです。
PR #13261 で何が変わったのか
保存しておいた PR #13261 の差分を見ると、`server.py` の `create_origin_only_middleware()` に、`Sec-Fetch-Site` を見て `cross-site` なら即座に `403` を返す処理が追加されています。
ざっくり言うと、次のような考え方です。
ブラウザが `cross-site` と言っているアクセスは危険かもしれない
なら早い段階で止めてしまおう
この意図自体は分かります。
ローカルアプリに対して、別のサイトから勝手にリクエストを飛ばされるようなケースを減らしたい、という発想です。
ただし、Paperspace のような環境では話が変わります。
なぜなら、正当な UI 起動そのものが `cross-site` に見えてしまうからです。
今回の変更はIssue #13245 と関係がある
Issue #13245 では、公開されている Security Advisory `GHSA-5xxr-jvhm-jxmj` に触れながら、
これは単なる CSRF の話ではない
デフォルト構成では未認証の RCE 連鎖につながる
という強い問題提起が行われています。
一方で、`server.py` の `origin_only_middleware` 周辺には、もともと
ランダムな Web サイトから localhost の ComfyUI に勝手にリクエストされるのを防ぎたい
本来は cookie などでもっと正しく守るべきだが、とりあえず防ぎたい
という意図がコメントとして残っています。
この 2 つを合わせて見ると、PR #13261 は「ブラウザ経由でローカルの ComfyUI に触れられる入口を狭める」という意味で、Issue #13245 で問題視されていた脅威モデルとかなり近い方向を向いた修正になっています。
ただし、ここで注意が必要です。
PR #13261 がやっているのは、あくまで `Sec-Fetch-Site` を使って browser-origin の cross-site アクセスを広く止めることです。
セキュリティ強化の方向性自体は Issue #13245 と整合している
ただし防御条件がやや粗く、localhost 向けの防御を reverse proxy 環境にもそのまま当ててしまった
その副作用として、Paperspace のような正当な UI 起動まで巻き込んだ
つまり今回の問題は何だったのか
一言で言えば、これです。
「ComfyUI の新しいセキュリティ条件が、Paperspace の正常な起動経路まで危険扱いしてしまった」
ここで大事なのは、Paperspace 側が壊れていたわけではない、という点です。
Paperspace は普通に公開 URL を発行し、普通に notebook 内へ転送していました。
一方の ComfyUI は、`cross-site` という情報を見て「怪しい」と判断しました。
でも Paperspace の場合、その `cross-site` は攻撃ではなく、ただの正常な画面表示でした。
この食い違いが、今回の不具合の本体です。
「URL 生成の問題」ではなかった理由
今回の症状だけを見ると、「TensorBoard 経由の URL が変になったのでは」と思いやすいです。
ですが、実際には URL は正しく生成されていました。
本当の流れは次の通りです。
ComfyUI の公開 URL は正しく作られる
ブラウザはその URL をちゃんと開く
そのリクエストは ComfyUI まで届く
しかし `server.py` が `cross-site` を理由に 403 を返す
その結果、ブラウザには UI ではなくブロック画面が見える
つまり、問題は「行き先が間違っていた」ことではなく、「到着後に入場拒否された」ことでした。
なぜローカル環境では目立ちにくいのか
ローカルで ComfyUI を使うときは、ブラウザが `127.0.0.1` や `localhost` に直接アクセスすることが多いです。
この場合は Paperspace のように前段で公開プロキシが挟まらないため、ブラウザが送るヘッダーの性質も変わります。
そのため、同じ `server.py` の変更でも、ローカルでは問題にならず、Paperspace のような構成でだけ表面化しやすい、という違いが出ます。
最後に
Paperspace 上で起きた今回の問題の直接の引き金は、PR #13261 による `server.py` の変更でした。
この PR はブラウザ経由の危険なアクセスを減らす意図で入っています。
ただし、Paperspace のような notebook + reverse proxy 環境では、そのルールが正常な UI 起動まで巻き込んでしまいました。
まさにPaperspaceを狙い撃ちするような変更になってしまっていました。
ということで、今回の問題に関しては、sever.pyの修正で対応可能です。
コメント