【ITニュース解説】TIL: CORS, IPs, and the Day My Demo Crashed 🔒

自分のPCで完璧に動作していたアプリケーションが、いざデモを行う段階になって上司のPCでは全く動かなくなるという状況は、多くのシステム開発者が一度は経験するであろう問題である。この問題の背景には、開発環境特有の設定やネットワークに関する基本的な理解の不足が隠されていることが少なくない。今回のケースもまさにそのような状況で、開発者は当初、バックエンドのクラッシュやCORS（Cross-Origin Resource Sharing）の設定ミスを疑ったが、ログを確認しても異常は見当たらなかった。

AIアシスタントの助言に従い、バックエンドのホストを0.0.0.0に変更し、フロントエンドのAPIアクセス先をサーバーのIPアドレスに設定したところ、アプリケーションは無事に動作するようになった。しかし、なぜ自分のPCでは以前の設定でも動いていたのか、なぜこの変更で動くようになったのか、という疑問が残った。この謎を解く鍵は、VS CodeのRemote-SSH機能が提供する「ポートフォワーディング」という機能にあった。

Remote-SSHを利用してリモートサーバー上で開発を行う際、VS Codeは自動的にサーバー側のポートを開発者のローカルPCのlocalhostに「転送（フォワード）」していたのである。具体的には、サーバー上で動作しているフロントエンドやバックエンドのアプリケーションが使用するポート（例えば6485や6489）が、開発者のローカルPCのlocalhost:6485やlocalhost:6489としてアクセス可能になっていた。この自動的なトンネル機能のおかげで、開発者は自分のPCのWebブラウザでlocalhost経由でサーバー上のアプリケーションにアクセスできており、あたかもアプリケーションがローカルPCで動いているかのように錯覚していた。

しかし、上司のPCからアクセスした場合、上司のPCにおけるlocalhostは上司自身のPCを指すため、サーバー上で動いているバックエンドには到達できない。これが「自分のPCでは動くのに、他のPCでは動かない」という現象の根本的な原因であった。VS Codeの自動ポートフォワーディングは開発を便利にする一方で、実際のネットワーク環境におけるアプリケーションの挙動を隠蔽し、問題を特定しにくくするという側面も持っている。

では、他のマシンからもアクセスできるようにするには、どのような設定が必要なのだろうか。ここで重要になるのが、バックエンドの「バインド先」とフロントエンドの「APIアクセス先」の設定である。

バックエンドのホスト設定でlocalhost（または127.0.0.1）を指定した場合、そのバックエンドは「そのサーバー自身からの接続」しか受け付けない。これは、アプリケーションが自分のマシンの中だけで通信することを許可している状態である。そのため、ネットワーク上の他のPCからIPアドレスを使ってアクセスしようとしても、その接続は拒否されてしまう。

これに対し、0.0.0.0という特別なIPアドレスを指定すると、バックエンドは「そのサーバーが持っているすべてのネットワークインターフェースからの接続」を受け付けるようになる。サーバーに割り当てられているLANやWi-FiなどのどのIPアドレスに対しても開かれている状態となるのだ。このように設定することで、上司のPCなど、同じネットワーク上の他のデバイスからでもバックエンドにアクセスできるようになる。

次に、フロントエンドがバックエンドにAPIを呼び出す際の設定も重要だ。フロントエンドはユーザーのWebブラウザ上で動作するため、ブラウザが動いているPCからバックエンドにアクセスする必要がある。このとき、フロントエンドのコード内でバックエンドのアドレスをhttp://localhost:6489のように設定していると、ブラウザは「そのブラウザが動いているPCのlocalhost」を探しに行ってしまう。当然、サーバー上のバックエンドには到達できない。したがって、フロントエンドからはバックエンドが実際に動作しているサーバーの「IPアドレス」または「ホスト名」を明示的に指定する必要がある。例えば、http://10.X.X.X:6489のように設定することで、ブラウザは正しいサーバーのバックエンドに接続できるようになる。

これらの設定変更によりデモは成功したが、場合によっては新たな問題も浮上することがある。Microsoftログインのような認証機能を利用する場合、認証プロバイダはセキュリティ上の理由から、リダイレクトURIとしてlocalhostまたはHTTPS接続を要求することが多い。サーバーのIPアドレスで直接アクセスした場合、これらの認証が機能しない可能性がある。開発時にはSSHのポートフォワーディングを手動で行うことで、ローカルのlocalhost経由で認証をクリアできるが、これはデモや本番環境でユーザーに求める運用方法ではない。このような場合は、サーバー側でHTTPSを適切に設定し、https://10.X.X.X:6485のようなURLでアクセスできるようにすることが、より適切な解決策となる。

そして、もう一つ忘れてはならないのがCORS（Cross-Origin Resource Sharing）である。CORSはWebブラウザが実装しているセキュリティ機能で、あるWebページ（オリジンA）から、異なるドメイン、プロトコル、ポートを持つ別のリソース（オリジンB）にアクセスする際に、オリジンBがそのアクセスを許可するかどうかを制御する仕組みである。開発者はバックエンドが特定のサーバーIPアドレスからのアクセスのみを許可するように設定していたため、フロントエンドが異なるマシン（例えば上司のPC）で動作している場合、その異なるオリジンからのリクエストはバックエンドによってブロックされてしまうことがあった。この問題を解決するには、バックエンドのCORS設定において、フロントエンドが実際に動作する可能性のあるすべてのオリジン（IPアドレスやホスト名）を明示的に許可リストに追加する必要がある。例えば、allowed_origins.append(f"http://{FRONT_END_IP}/")のように、フロントエンドが動作するIPアドレスも許可するように設定することで、CORSによるブロックを防ぐことができる。

以上の経験から得られる教訓は多岐にわたる。localhostは「自分のPC」を意味し、サーバーのIPアドレスとは異なるということを常に意識すること。VS CodeのRemote-SSHによるポートフォワーディングは開発を便利にするが、それがネットワークの実際の挙動を隠蔽し、問題の原因を見えなくすることがあるため、その特性を理解しておくことが重要である。バックエンドは他のマシンからのアクセスを許可するために0.0.0.0にバインドし、フロントエンドはバックエンドのサーバーIPアドレスやホスト名を正しく指定すること。CORS設定では、フロントエンドが実際にデプロイされる可能性のあるすべてのオリジンを考慮し、適切に許可設定を行うこと。そして最も重要なのは、デモや本番環境に近い「クリーンな環境」で、ポートフォワーディングのような開発補助機能がない状態でテストを行うことである。これにより、予期せぬネットワーク関連の問題を早期に発見し、デモ当日のトラブルを未然に防ぐことができるだろう。ネットワークの仕組みを正しく理解し、適切な設定を行うことが、安定したアプリケーション開発には不可欠である。