ByteScope

よく使うポート番号

そのポートで何が動くのか、外部に開けてよいのか、いま掴んでいるのは誰か。

ファイルはブラウザから送信されません — 処理はすべてローカルで行われます。

困っているポートから入ってください。どのページも、そこで動くサービス、外部に開けてよいかどうか、そして macOS・Linux・Windows それぞれで「いま誰が掴んでいるか」を一発で出すコマンドを載せています。

カテゴリで絞り込む
ポートサービストランスポートそこで動くもの
21FTPTCPFTP の制御用コネクション。コマンドと 3 桁の応答コードが流れるのはこのポートで、ファイルの中身そのものは、ファイアウォールに誰も教えていない別のポートの上を流れます。
22SSHTCPsshd が待ち受けるポート。その裏には `scp`、`rsync`、SSH 越しの `git`、トンネル、そして SFTP がぶら下がっていて、ここが 1 つ拒否されるだけで別々の 5 つが同時に壊れます。
23TelnetTCP平文のまま端末をつなぐポート。スイッチやカメラ、組み込みボードでは今も出荷時の管理口で、そしてうっかり開けると数分でスキャナーに見つかるポートでもあります。
25SMTPTCPサーバー間でメールを中継するためのポート。アプリから直接叩くべきではない番号であり、クラウドの VM でタイムアウトするのはメールサーバーが落ちているからではなく、事業者が塞いでいるからです。
53DNSTCP/UDP名前解決のためのポートで、UDP と TCP の両方を使います。そして最近の Linux デスクトップでは既に systemd-resolved が握っているので、dnsmasq や Pi-hole が起動しません。
80HTTPTCP平文 HTTP のポート。いまどきは 443 へのリダイレクトを返すだけの存在ですが、閉じてしまうと証明書の更新が止まりますし、一般ユーザーのままでは bind した時点で失敗します。
443HTTPSTCP/UDPHTTPS のポート。ただし HTTP/3 以降は UDP のポートでもあるので、TCP だけを見るチェックは「誰も待ち受けていない」と言いながら、実は半分のトラフィックが捌かれている状態を見落とします。
3306MySQLTCPMySQL・MariaDB・Percona が従来のクライアントプロトコルを待ち受けるポート。ドライバが「届かない」と言ってくるのもここです。
3389RDPTCP/UDPWindows のリモートデスクトップが待ち受けるポート。サービスが起動しないときは既に誰かに取られていて、クライアントが回り続けるときは黙って捨てられています。
5432PostgreSQLTCPPostgreSQL のクラスタが待ち受けるポート。psql に断られたときの原因は、ループバック限定か、二つ目のクラスタが占有しているか、pg_hba.conf に止められているかのどれかです。
5900VNCTCPVNC が話す RFB プロトコルのベースポート。ビューアがつながらないのに、サーバーは 5901 で平然と動いている——その理由もここにあります。
6379RedisTCPRedis が RESP を待ち受けるポート。クライアントが「届かない」と言ってくる番号であり、外に出したキャッシュが数時間で見つけられる番号でもあります。
8080HTTP alternateTCP80 が使えないときに開発サーバーや Tomcat、プロキシが掴みにいくポート。そして、あなたが必要になった瞬間には既に誰かが掴んでいるポート。
8443HTTPS alternateIANA 割り当てなしTCP443 の非特権版。一般ユーザーでも bind できるポートで TLS を話すという位置づけで、Tomcat やアプライアンスの管理画面が真っ先に選ぶ番号です。
27017MongoDBTCPmongod と mongos が既定で待ち受けるポート。ドライバがサーバー選択に 30 秒黙って失敗し続けるのもここです。

このツールについて

ポートが原因になった瞬間のために ポート番号を好奇心で調べる人はほとんどいません。サーバーが起動しない、クライアントがつながらない、スキャンしたら誰も心当たりのないものが待ち受けていた——だから調べるわけです。そこでこのリファレンスは、まず詰まりを外すもの、つまり macOS・Linux・Windows でそのポートを掴んでいるプロセスを名指しするコマンドを先に置き、そのサービスが何なのかという話は後回しにしています。

三つのコマンドと、それぞれの落とし穴 「このポートは誰のものか」への答え方は環境ごとに違い、しかもどれにも罠があります。macOS の lsof は sudo を付けないと自分のプロセスしか見えないので、Docker やシステムユーザーが起動したサーバーは存在しないように見えます。Linux の ss も同じ理由で所有プロセスの列が空になります。Windows の netstat は findstr で絞る都合上、部分一致なので :3306 は :33060 にも当たります。各ページは打つべきコマンドだけでなく、出力の読み方まで書いています。

割り当てなのか、慣習なのか ポート番号の公式な意味を決めているのは IANA の Service Name and Transport Protocol Port Number Registry だけです。日常的に使われている組み合わせでも登録されていないものは多く、逆に登録されているのに実務では無視されている組み合わせもあります。だから各ページはそのどちらなのかを必ず書き分けます。範囲も同じレジストリが決めていて、0-1023 はシステムポートで Unix 系では特権がないとバインドできず、1024-49151 はユーザーポート、49152-65535 はクライアント側が使う動的ポートです。ただし最後の範囲に OS が従っているとは限らず、Linux の既定のエフェメラルポートは 32768-60999 です。

よくある質問

そのポートを使っているものを調べるには？

macOS なら sudo lsof -nP -iTCP:8080 -sTCP:LISTEN、Linux なら sudo ss -tlnp 'sport = :8080'、Windows なら netstat -ano | findstr :8080 で PID を拾い、tasklist /FI "PID eq <pid>" で名前に変換します。どれもバインドしているアドレスまで出るので、「他のマシンから届くのか」という次の疑問も同時に片付きます。

使用中のポートを空けるには？

まず上のコマンドで持ち主を確認してください。「さっき起動した同じサーバーが残っていた」であることが多く、その場合は kill よりきちんと停止するほうが安全です。1、2 分待つと勝手に空くなら、そもそも誰も掴んでいません。接続が残ったまま閉じたソケットは TIME_WAIT に留まり、SO_REUSEADDR を設定しないプログラムはタイマーが切れるまで bind に失敗します。Windows では何も待ち受けていないのに bind が失敗することもあり、これは Hyper-V や WSL2、Docker が起動時にポート帯を予約したケースです。netsh interface ipv4 show excludedportrange protocol=tcp で一覧が出ます。

ポート番号で話すプロトコルが決まるの？

決まりません。ポート番号はパケットをソケットへ振り分けるための 16 ビットのラベルにすぎず、何を話すかを強制する仕組みはどこにもありません。443 で TLS を話さないものが待ち受けることもできますし、8080 の Web サーバーは番号が珍しいだけの普通の HTTP サーバーです。慣習を知っておく価値があるのは「たぶん何がいるか」が分かるからで、実際の応答を読んで判断するために nmap -sV が存在します。

外部に開けてよいポートは？

敵対的なネットワークを前提に設計されたもの、つまり 443 の HTTPS と、パスワード認証を切った 22 の SSH くらいです。実際に事故になるのはデータベースのポートで、3306・5432・6379・27017 はいずれも認証こそありますが、外に出すということはその認証をインターネット全体の前に置くということです。新しいリスナーは数時間でスキャナーに見つかります。プライベートネットワークや VPN、SSH トンネル越しに届かせるのが基本で、どうしても経路が必要なら送信元アドレスでファイアウォールを絞ってください。

well-known・登録済み・動的ポートの違いは？

IANA レジストリが定める三つの範囲です。0-1023 のシステムポートがいわゆる well-known で、Unix 系ではバインドに root か明示的に付与された権限が要ります。多くのソフトが 80 ではなく 8080 を既定にしているのはまさにこれが理由です。1024-49151 のユーザーポートは申請に応じて登録されます。49152-65535 の動的ポートはクライアントが発信時に選ぶ一時的な送信元ポート用で、何かに登録されることは想定されていません。