1. 概要
Uvicorn で --host 0.0.0.0 --port 5000 を指定し、ホストのファイアウォールを sudo ufw enable（有効化）したところ、外部サーバとして立ち上がりローカルPCから接続可能になった。ここでは なぜ繋がるようになったのか を、ネットワークの流れと実証コマンド付きで整理する。
2. 結論（先取り）
-
--host 0.0.0.0により 全NICで 5000/TCP を待受 するようになった。 - UFW などの どこかのFWレイヤで 5000/TCP が許可 されていた（既存ルール、アプリプロファイル、または上位のセキュリティグループ等）。
- 結果として、クライアント → サーバのパケットが ホストの待受ソケットまで到達 し、Uvicorn が応答できる状態になった。
重要：UFW の既定は「受信 deny」。接続できている事実は、明示的な許可ルールがあるか、あるいは**別レイヤでの公開（LB/プロキシ等）**が効いていることを示す。
3. 変化点の技術的意味
3.1 --host 0.0.0.0
- ループバック（
127.0.0.1:5000）のみの待受 → 外部インターフェース（例：eth0 のグローバルIP）でも待受 に変化。 - カーネルのソケットは
0.0.0.0:5000で LISTEN。外部からの SYN が到達すれば Uvicorn が握手・応答できる。
3.2 sudo ufw enable
-
ホストFWを有効化。既定では Incoming=Deny, Outgoing=Allow。
-
繋がっている＝どこかで 5000/TCP 許可：
- 例）
ufw allow 5000/tcpが既に設定済み - 例）アプリの UFW プロファイルを許可済み
- 例）クラウドのセキュリティグループ/上位FWで 5000/TCP 許可 + ホスト側も許可
- 例）
4. ネットワークの流れ（Before/After）
BEFORE（つながらない）
[Client] --TCP:5000--> [Server(Global IP)]
|
v
カーネル待受: 127.0.0.1:5000
|
x 外部NICで未待受 or FWで拒否
AFTER（つながる）
[Client] --TCP:5000--> [Server(Global IP)]
|
v
UFW/上位FW: 5000/tcp 許可
|
v
LISTEN: 0.0.0.0:5000 (全NIC)
|
v
Uvicorn / app
5. 実証と確認ポイント
-
待受確認（OKの証跡）
ss -ltnp | grep :5000 # 例: LISTEN 0 2048 0.0.0.0:5000 0.0.0.0:* users:("python",pid=...,fd=...) -
UFW ルール確認（許可の有無）
sudo ufw status verbose # ここに 5000/tcp ALLOW が出ていればホストFWで通っている # 無い場合は明示許可: sudo ufw allow 5000/tcp -
疎通確認（クライアント側）
curl -v http://<サーバのグローバルIP>:5000/ # あるいは nc -vz <サーバIP> 5000
6. 運用上の注意（中級向け）
-
公開範囲の最小化：
-
固定IPのみ許可
sudo ufw delete allow 5000/tcp sudo ufw allow from <YourIP> to any port 5000 proto tcp -
もしくは Uvicorn は
127.0.0.1待受に戻し、Nginx/ALB を前段に置いてTLS終端・レート制限・ログ収集を行う。
-
-
本番プロセス：
--reloadは開発専用。必要に応じて--workers Nを指定。 -
可観測性：
access_log、上位FW/ロードバランサのログと合わせて経路を可視化。
7. まとめ
-
--host 0.0.0.0で「外でも待受」になった。 - UFW/上位FWのどこかで 5000/TCP が許可され、パケットが落ちなくなった。
- その結果として、外部クライアントからの接続が Uvicorn のソケットに到達し、応答できるようになった。公開後は誰に開くかを必ず制御し、プロキシやTLSで安全に運用すること。