ポート番号一覧【2026年版】well-knownポートと確認コマンドの早見表

ポート番号とは、1台のコンピューターの中で「どのプログラム（サービス）に通信を渡すか」を表す 0〜65535 の番号です。 IPアドレスが「建物の住所」なら、ポート番号は「部屋番号」にあたります。80 は HTTP、443 は HTTPS、22 は SSH、3306 は MySQL というように、よく使うサービスには決まった番号（well-known ポート／ウェルノウンポート）があり、「この番号は何？」「このサービスのポートは？」を調べるときの共通言語になっています。

この記事では、検索されやすい30余りのポートの早見表と、用途別の一覧（Web・メール・データベース・コンテナ・監視・開発ツールなど、170行超）をまとめました。番号の根拠は、Linux の /etc/services（Ubuntu 24.04、netbase 6.4）と各製品の公式ドキュメントで一つずつ確かめています。後半では、ss・lsof・netstat・nc・curl でポートが開いているか確認するコマンドをすべて実行結果つきで載せ、Address already in use や「127.0.0.1 と 0.0.0.0 の違い」も再現して、つながらないときの切り分け手順まで追えるようにしました。

ポート番号の早見表（検索されやすい30ポート）

まずは「よく検索される番号」だけを1枚にまとめました。TCP・UDP の列は、そのサービスが主に使うトランスポートプロトコルです。

早見表のうち、1521・5900・8443 以外はこの環境の /etc/services か各製品の公式ドキュメントで番号を確認しています（根拠の取り方は次の章で説明します）。1521・5900・8443 は /etc/services（netbase 6.4）には登録がなく、一般に知られた既定値として載せています。

ポート番号とは何かを3分で押さえる

IPアドレスが住所、ポート番号が部屋番号

通信の宛先は「IPアドレス＋ポート番号」のセットで決まります。 IPアドレスだけでは「どのコンピューターか」までしか分からず、そのコンピューターの中で動いている Web サーバー・メールサーバー・データベースのどれに届けるかを決めるのがポート番号です。マンションに例えると、IPアドレスが建物の住所、ポート番号が部屋番号で、192.0.2.10:443 は「192.0.2.10 という建物の 443 号室（HTTPS）」という意味になります。

ポート番号は 16 ビットの整数なので 0〜65535 の範囲です（2**16 - 1 を Python で計算すると 65535）。この番号を使うのは TCP と UDP（と SCTP などの一部のプロトコル）で、どちらもポート番号の空間は独立しています。

IANA が決めている3つの区分（well-known ポートとは）

ポート番号の割り当ては IANA（Internet Assigned Numbers Authority）が管理しており、RFC 6335 で次の3区分が定義されています（RFC 6335 の Section 6 を今回開いて確認）。

「well-known ポート」は厳密には 0〜1023 のことですが、日常会話では 3306 や 6379 のような「有名な登録済みポート」も含めて呼ばれることが多いので、この記事の一覧は両方を載せています。なお Linux で 1023 以下のポートを待ち受けるには管理者権限（root か CAP_NET_BIND_SERVICE）が必要で、この挙動はよくある質問の章で再現しています。

エフェメラルポートの範囲（Linux の実行結果）

クライアント側（ブラウザや curl）が通信するとき、送信元ポートは OS が空いている番号を自動で割り当てます。これがエフェメラルポート（短命ポート）です。Linux の範囲は /proc/sys/net/ipv4/ip_local_port_range で確認でき、この環境（Ubuntu 24.04）では 32768〜60999 でした。

cat /proc/sys/net/ipv4/ip_local_port_range

32768   60999

IANA の区分（49152〜）とは少しずれていて、Linux は 32768 から使います。実際に curl でローカルの 7692 番に接続した直後に ss で見ると、送信元に 34522 番が使われていました（下の TIME-WAIT 行の右側）。

curl -s http://127.0.0.1:7692/ > /dev/null; ss -tan 'sport = :7692'

State     Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN    0      5            0.0.0.0:7692      0.0.0.0:*
TIME-WAIT 0      0          127.0.0.1:7692    127.0.0.1:34522

Windows の既定範囲は 49152〜65535 で、netsh int ipv4 show dynamicport tcp で確認できます（Windows は今回未実行。一般に知られた仕様として記載）。

同じ番号を TCP と UDP で別々に使える（実行結果）

TCP と UDP のポート空間は独立しているので、同じ番号を TCP と UDP で同時に待ち受けできます。 Python で 7697 番を両方 bind して ss で見ると、udp と tcp の行が並びます。

# tcp_udp_same_port.py（Python 3.11）
import socket, time
tcp = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
tcp.bind(("127.0.0.1", 7697)); tcp.listen()
udp = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
udp.bind(("127.0.0.1", 7697))
print("TCP 7697 と UDP 7697 を同時に待ち受け中")
time.sleep(30)

python3 tcp_udp_same_port.py &
ss -tulnp 'sport = :7697'

Netid State  Recv-Q Send-Q Local Address:Port Peer Address:PortProcess
udp   UNCONN 0      0          127.0.0.1:7697      0.0.0.0:*    users:(("python3",pid=1319,fd=4))
tcp   LISTEN 0      128        127.0.0.1:7697      0.0.0.0:*    users:(("python3",pid=1319,fd=3))

これが「53 は TCP と UDP の両方」「443/UDP は HTTP/3」のように、同じ番号でも TCP と UDP で別のプロトコルが動く理由です。RFC 6335 以降、IANA は申請されたトランスポートプロトコルにだけ番号を割り当てる運用になっています（Section 8.1.2 を確認）。

番号の調べ方：/etc/services と getent

Linux には IANA 登録済みのポートの一覧 /etc/services（Debian/Ubuntu では netbase パッケージ）が入っています。「この番号は何？」も「このサービスは何番？」も getent services で引けます（grep でも可）。 この記事で「/etc/services で確認」と書いている番号は、すべて次のように実際に引いたものです。

getent services 443        # 番号 → サービス名
getent services 443/udp
getent services ssh        # サービス名 → 番号
getent services 6379
getent services 27017      # 登録がなければ何も出ず、終了コード 2
echo "exit=$?"

https                 443/tcp
https                 443/udp
ssh                   22/tcp
redis                 6379/tcp
exit=2

grep -wE '^(ssh|http|https|smtp)' /etc/services

ssh     22/tcp              # SSH Remote Login Protocol
smtp        25/tcp      mail
http        80/tcp      www     # WorldWideWeb HTTP
https       443/tcp             # http protocol over TLS/SSL
https       443/udp             # HTTP/3
http-alt    8080/tcp    webcache    # WWW caching service

この環境の /etc/services は 361 行で、冒頭に「IANA の登録簿から更新している」「必要なら nmap パッケージの一覧を使う」と書かれています。MongoDB（27017）や Kafka（9092）のように製品ごとに定めた番号は載っていないので、そうした番号は各製品の公式ドキュメントで確認しました（記事末尾の「参考（出典）」に列挙）。開けなかったものは「一般に知られた既定値」と注記しています。

用途別のポート番号一覧（170行超）

「公開の目安」列は、インターネットに公開して使うのが前提のポートか、内部ネットワーク限定で使うのが基本のポートかを示しています。「内部限定が基本」のポートを外から使うときは、VPN やリバースプロキシ、接続元の IP 制限を挟むのが定石です。各表の下に、番号をどこで確認したか（/etc/services／公式ドキュメント／一般に知られた既定値）を書いています。

Web・HTTP のポート番号

根拠：80・443・8080・8081 は /etc/services で確認（8081 は tproxy として登録）。3000 は Grafana 公式ドキュメント、8000 は python3 -m http.server --help の表示（default: 8000）で確認。それ以外は一般に知られた既定値。

メールのポート番号

根拠：25・465・587・110・995・143・993 はすべて /etc/services で確認（465 は submissions、587 は submission、143 は imap2 として登録）。

ファイル転送・共有のポート番号

根拠：20・21・22・69・139・445・2049・873・989・990・548・111 は /etc/services で確認（445 は microsoft-ds、139 は netbios-ssn、548 は afpovertcp として登録）。115 は一般に知られた仕様。

リモート操作のポート番号

根拠：22・23・3389 は /etc/services で確認。5900〜5902・5985・5986 は一般に知られた既定値。

名前解決・時刻・ネットワーク管理のポート番号

根拠：53・853・67・68・546・547・123・161・162・514・6514・179・520・1812・1813・5353 は /etc/services で確認。1645/1646 は /etc/services では datametrics／sa-msg-port として登録されており、RADIUS の旧既定としては一般に知られた値。5355・1900 は一般に知られた既定値。

認証・ディレクトリのポート番号

根拠：88・389・636・464・1812・1813・49 は /etc/services で確認。3268/3269 は一般に知られた既定値。

データベースのポート番号

根拠：1433・1434・3306・5432 は /etc/services で確認。27017〜27019 は MongoDB 公式ドキュメント（Default MongoDB Port）で確認。1521・33060・50000・5984・7000/7001・9042・8529 は一般に知られた既定値（なお /etc/services の 7000 は bbs／afs3-fileserver という別の登録です）。

キャッシュ・メッセージングのポート番号

根拠：6379・5672・5671 は /etc/services で確認（6379 は Redis 公式の redis.conf「default is 6379」でも確認）。9092 は Kafka 公式クイックスタートで確認。26379・11211・15672・9093・2181・4222・1883・8883・61616・61613 は一般に知られた既定値。

検索・ログ・監視のポート番号

根拠：9200・9300 は Elasticsearch 公式（Networking settings）、9090 は Prometheus 公式（Getting started）、3000 は Grafana 公式（Configure Grafana）で確認。10050・10051 は /etc/services で確認。残りは一般に知られた既定値。

コンテナ・オーケストレーションのポート番号

根拠：6443・2379〜2380・10250・10256・10257・10259・30000〜32767 は Kubernetes 公式（Ports and Protocols）で確認（公式の表は NodePort の 30000〜32767 だけ TCP と UDP の両方の行があり、それ以外はすべて TCP）。179 は /etc/services で確認。2375・2376・8500・8600・4789 は一般に知られた既定値。

開発でよく使う既定ポート（何のツールの既定か）

根拠：8000 は python3 -m http.server --help、9229 は node --help の表示で確認（Node 22.22.2）。3000 は Grafana 公式、8080・8081 は /etc/services で確認。残りは一般に知られた既定値（1313 は /etc/services では xtel として別の登録があります）。

VPN・トンネルのポート番号

根拠：500・4500・1194・1701・1080・443 は /etc/services で確認。51820・1723 は一般に知られた既定値。

Windows 系のポート番号

根拠：135・137・138・139・445・3389・88・389・636・1433 は /etc/services で確認。5985/5986・3268/3269・5355・1900/2869 は一般に知られた既定値。

その他よく聞かれる番号

根拠：7・13・19・37・43・79・113・554・631・5060/5061・5222/5269・5353・6000・6667/6697・9418・10000 は /etc/services で確認。1900・3478・5355・6660〜6669 の範囲・6881〜6889・8291 は一般に知られた既定値。

ポート 0 の挙動は Python で確認できます。 0 を指定して bind すると、OS がエフェメラルポートの範囲から空いている番号を選びます（この環境では 52077 が選ばれました。実行のたびに変わります）。

import socket
s = socket.socket()
s.bind(("127.0.0.1", 0))      # 0 を指定すると OS が空きポートを選ぶ
print("OS が選んだポート:", s.getsockname()[1])
s.close()

OS が選んだポート: 52077

ポートが開いているか確認するコマンド（すべて実行結果つき）

ここからは「ポートを確認する」コマンドです。「自分のマシンが待ち受けているか（ss・lsof・netstat）」と「相手のポートに届くか（nc・curl・/dev/tcp）」は別の確認なので、分けて載せます。待ち受け役として、作業フォルダで Python の簡易 HTTP サーバーを 7692 番で起動して使いました。

検証環境と待ち受け役の起動

cd 作業用フォルダ          # 公開してよいファイルだけがあるフォルダで起動する
echo '<h1>port test 7692</h1>' > index.html
python3 -m http.server 7692 &

Serving HTTP on 0.0.0.0 port 7692 (http://0.0.0.0:7692/) ...

待ち受けているポートを一覧する：ss -tulnp

ss -tulnp は「TCP（t）と UDP（u）の、待ち受け中（l）のソケットを、名前解決せず数字のまま（n）、プロセス名つき（p）で」表示します。 現在の Linux ではこれが基本形です。

ss -tulnp

Netid State  Recv-Q Send-Q Local Address:Port  Peer Address:PortProcess
tcp   LISTEN 0      200        127.0.0.1:5432       0.0.0.0:*    users:(("postgres",pid=521,fd=6))
…（省略）…
tcp   LISTEN 0      5            0.0.0.0:7692       0.0.0.0:*    users:(("python3",pid=1081,fd=3))

見方のポイントは次の3つです。

Process 列は root（または sudo）で実行したときに表示されます。一般ユーザーだと自分のプロセス以外は空欄になるので、PID が出ないときは sudo ss -tulnp を試してください。

特定のポートだけを見る：ss・lsof・netstat

特定の番号だけ知りたいときは、ss のフィルター 'sport = :番号' が一番速いです。 ss -tln | grep ':7692' でも同じことができます。

ss -tlnp 'sport = :7692'

State  Recv-Q Send-Q Local Address:Port Peer Address:PortProcess
LISTEN 0      5            0.0.0.0:7692      0.0.0.0:*    users:(("python3",pid=1081,fd=3))

lsof -i :番号 は「そのポートを開いているファイル（ソケット）」を一覧します。接続中のクライアント側も含めて全部出るので、待ち受けだけに絞るなら -sTCP:LISTEN を付けます。-nP は名前解決とポート名変換（7692 を http-alt のように表示すること）を止めるオプションで、出力が安定します。

lsof -i :7692

COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
python3 1081 root    3u  IPv4   3761      0t0  TCP *:7692 (LISTEN)

lsof -nP -iTCP:7692 -sTCP:LISTEN

COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
python3 1081 root    3u  IPv4   3761      0t0  TCP *:7692 (LISTEN)

netstat -tulnp は ss -tulnp と同じ意味のオプションで、net-tools パッケージが入っていれば使えます（Ubuntu 24.04 では apt install net-tools で追加。この環境には入っていました）。新しい環境では ss が標準なので、netstat が無ければ ss に読み替えてください。

netstat -tulnp | grep -E 'Proto|:7692'   # 見出し行と 7692 の行だけ表示

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:7692            0.0.0.0:*               LISTEN      1081/python3

3つのコマンドの使い分けを表にまとめます。

相手のポートに届くか確かめる：nc・curl・bash の /dev/tcp

「待ち受けている」と「届く」は別です。相手側（別ホストやコンテナ）から見て接続できるかは、クライアント役のコマンドで確かめます。

nc -zv ホスト 番号 は、接続だけして（-z）結果を表示（-v）します。開いていれば succeeded!、閉じていれば Connection refused です。

nc -zv localhost 7692        # 開いているポート
echo "exit=$?"
nc -zv localhost 7693        # 何も待ち受けていないポート
echo "exit=$?"

Connection to localhost (127.0.0.1) 7692 port [tcp/*] succeeded!
exit=0
nc: connect to localhost (127.0.0.1) port 7693 (tcp) failed: Connection refused
exit=1

タイムアウトを付けるなら -w 秒数 です。応答のない宛先（ファイアウォールで落とされている、経路がないなど）は timed out になります。この違いが切り分けの鍵になるので、後の章でまとめます。

nc -zv -w 3 10.255.255.1 7692

nc: connect to 10.255.255.1 port 7692 (tcp) timed out: Operation now in progress

curl -v は、TCP の接続だけでなく HTTP の応答まで確かめられます。Connected to の行で接続成功、< HTTP/1.0 200 OK の行でアプリケーションが応答していることが分かります。

curl -v -s -o /dev/null http://127.0.0.1:7692/

*   Trying 127.0.0.1:7692...
* Connected to 127.0.0.1 (127.0.0.1) port 7692
> GET / HTTP/1.1
> Host: 127.0.0.1:7692
> User-Agent: curl/8.5.0
> Accept: */*
>
* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
< Server: SimpleHTTP/0.6 Python/3.11.15
< Date: Fri, 02 Oct 2026 06:26:18 GMT
< Content-type: text/html
< Content-Length: 24
…（省略）…
* Closing connection

ステータスコードだけ欲しいときは -w '%{http_code}' が便利です。接続できないときは 000 と終了コード 7、タイムアウトは終了コード 28 になります。

curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:7692/
curl -v -s http://127.0.0.1:7693/; echo "exit=$?"
curl --connect-timeout 3 http://10.255.255.1:7692/; echo "exit=$?"

200
*   Trying 127.0.0.1:7693...
* connect to 127.0.0.1 port 7693 from 127.0.0.1 port 32948 failed: Connection refused
* Failed to connect to 127.0.0.1 port 7693 after 0 ms: Couldn't connect to server
* Closing connection
exit=7
curl: (28) Failed to connect to 10.255.255.1 port 7692 after 3002 ms: Timeout was reached
exit=28

nc も curl も入っていない最小構成のコンテナでは、bash の /dev/tcp 疑似デバイスで確認できます。 timeout 1 を付けておくと、応答がない宛先でも 1 秒で戻ります。

timeout 1 bash -c '</dev/tcp/127.0.0.1/7692' && echo open
timeout 1 bash -c '</dev/tcp/127.0.0.1/7693' && echo open || echo closed

open
bash: connect: Connection refused
bash: line 1: /dev/tcp/127.0.0.1/7693: Connection refused
closed

UDP は接続の概念がないため、nc -zuv -w 1 ホスト 番号 で succeeded! と出ても「送れた」ことまでしか分かりません（この環境では 7697/UDP の待ち受けありで succeeded!、待ち受けなしの 7698/UDP は表示なしで終了コード 1 でした）。

ポートを使っているプロセスを特定して止める（PID で）

止めるときは必ず PID を特定してから kill PID にします。 名前で広く止めるコマンド（pkill -f python など）は、同じ名前の別のプロセスまで止めてしまうので、PID を確認する一手間が安全です。ここでは 127.0.0.1 で待ち受けていた 7694 番のサーバー（この後の「127.0.0.1 と 0.0.0.0 の違い」で使ったもの）を止めます。

lsof -t -i :7694                                   # PID だけ出す
ss -tlnp 'sport = :7694' | grep -oP 'pid=\K[0-9]+' # ss から PID を抜き出す
ps -o pid,user,etime,cmd -p "$(lsof -t -i :7694)"  # 何のプロセスか確認

1218
1218
  PID USER         ELAPSED CMD
 1218 root           00:31 python3 -m http.server --bind 127.0.0.1 7694

kill 1218            # まず SIGTERM（通常終了のお願い）
sleep 1
ss -tlnp 'sport = :7694'
lsof -i :7694; echo "lsof exit=$?"
nc -zv localhost 7694

State Recv-Q Send-Q Local Address:Port Peer Address:PortProcess
lsof exit=1
nc: connect to localhost (127.0.0.1) port 7694 (tcp) failed: Connection refused

ss の結果が見出し行だけになり、lsof は該当なし（終了コード 1）、nc は Connection refused に変わりました。kill PID で止まらないときだけ kill -9 PID（SIGKILL）を使います。1行で済ませたいときは kill "$(lsof -t -i :7694)" と書けます。

Windows・Mac での確認コマンド（書き方のみ、未実行）

Windows と macOS は今回の環境では実行していないため、書き方だけ載せます（一般に知られたコマンドです）。

macOS には ss も netstat -p もないため、lsof が基本になります。netstat -an | grep LISTEN は使えますが、プロセス名は出ません。

つながらないときの切り分け手順（エラー対処）

「ポートがつながらない」は、エラー文で原因の層がほぼ決まります。 次の表の上から順に見ていくと、確認の往復が少なくて済みます。

ポイントは Connection refused（届いたが待ち受けがない）と timed out（届いていない）を区別することです。refused ならサーバー側の設定、timed out なら間にあるファイアウォールや経路を疑います。

1. Address already in use を再現する

同じ 7692 番で2つ目の http.server を起動すると、Python では OSError: [Errno 98] Address already in use、Node.js では EADDRINUSE になります（別記事「Address already in use の解決方法」で詳しく扱っているので、ここでは要点のみ）。

python3 -m http.server 7692      # 1つ目が動いている状態で2つ目を起動

Traceback (most recent call last):
…（省略）…
  File "/usr/lib/python3.11/socketserver.py", line 472, in server_bind
    self.socket.bind(self.server_address)
OSError: [Errno 98] Address already in use

node -e "require('net').createServer().listen(7692, '0.0.0.0', () => console.log('listening')).on('error', e => { console.error(e.message); process.exit(1) })"

listen EADDRINUSE: address already in use 0.0.0.0:7692

対処は2択です。使っているプロセスを PID で止める（前の章の手順）か、ポートを変えて起動する（python3 -m http.server 7693、PORT=3001 npm run dev など）かです。サーバーを止めた直後だけ起動できない場合は、TIME-WAIT の接続が残っている可能性があるので、数十秒待つかアプリ側で SO_REUSEADDR を有効にします（Python の http.server は allow_reuse_address = 1 が既定で、ソース /usr/lib/python3.11/http/server.py の 136 行目で確認できます）。

2. 127.0.0.1 と 0.0.0.0 の違いを再現する

127.0.0.1 で待ち受けると「自分自身からの接続」だけを受け付け、0.0.0.0 で待ち受けると「すべてのネットワークインターフェース」で受け付けます。 「ローカルでは動くのに、別のマシンやコンテナの外から見えない」の原因で最も多いのがこれです。

python3 -m http.server は既定で 0.0.0.0（すべてのインターフェース）、--bind 127.0.0.1 を付けると自分自身だけになります。両方を起動して ss で見比べます。

python3 -m http.server 7692 &                        # 既定（0.0.0.0）
python3 -m http.server --bind 127.0.0.1 7694 &       # 127.0.0.1 だけ
ss -tlnp '( sport = :7692 or sport = :7694 )'

Serving HTTP on 0.0.0.0 port 7692 (http://0.0.0.0:7692/) ...
Serving HTTP on 127.0.0.1 port 7694 (http://127.0.0.1:7694/) ...
State  Recv-Q Send-Q Local Address:Port Peer Address:PortProcess
LISTEN 0      5          127.0.0.1:7694      0.0.0.0:*    users:(("python3",pid=1218,fd=3))
LISTEN 0      5            0.0.0.0:7692      0.0.0.0:*    users:(("python3",pid=1081,fd=3))

次に、このマシンに付いている IP アドレス（hostname -I）宛てに curl します。これは「別のマシンから接続したとき」と同じ経路を通る確認方法です。

hostname -I
curl -s -o /dev/null -w 'HTTP %{http_code}\n' http://192.0.2.2:7692/   # 0.0.0.0 で待ち受け
curl -s -o /dev/null -w 'HTTP %{http_code}\n' http://192.0.2.2:7694/   # 127.0.0.1 で待ち受け
curl http://192.0.2.2:7694/
curl -s -o /dev/null -w 'HTTP %{http_code}\n' http://127.0.0.1:7694/   # 自分自身からなら届く

192.0.2.2
HTTP 200
HTTP 000
curl: (7) Failed to connect to 192.0.2.2 port 7694 after 0 ms: Couldn't connect to server
HTTP 200

0.0.0.0 の 7692 番は自分の IP 宛てでも 200、127.0.0.1 の 7694 番は自分の IP 宛てだと接続できず、127.0.0.1 宛てなら 200 になりました。Docker コンテナの中で開発サーバーが 127.0.0.1 で待ち受けていると、-p 3000:3000 でポートを公開してもホストから届かないのは、まさにこの挙動です。主なツールの指定方法を表にまとめます。

逆に、データベースやキャッシュは 127.0.0.1 のままが安全側です。この環境の PostgreSQL も 127.0.0.1:5432 で待ち受けていました。外から使いたい場合は、0.0.0.0 にするより SSH ポートフォワードや VPN で届かせる方が、公開範囲を広げずに済みます。

3. そもそも待ち受けていない

ss -tulnp に該当ポートが出てこなければ、サーバーが起動していないか、別のポートで起動しています。起動時のログ（Serving HTTP on ... port 7692 のような行）と設定ファイルの port／listen の値を見比べるのが近道です。Docker なら docker ps の PORTS 列と docker logs コンテナ名 で、コンテナ内のアプリがどのポートで起動したかを確認します。

ss -tulnp | grep ':7693'; echo "exit=$?"     # 何も出なければ待ち受けていない

exit=1

4. ファイアウォールで止まっている（確認コマンドのみ、未実行）

待ち受けていて、同じホストからは届くのに外からは timed out になる場合は、ホストのファイアウォールを確認します。ufw・firewalld・iptables はこの環境では実行していないため、確認コマンドの書き方だけ載せます。

# Ubuntu（ufw）
sudo ufw status verbose            # 現在のルール一覧
sudo ufw allow 7692/tcp            # 許可を追加する例

# RHEL 系（firewalld）
sudo firewall-cmd --list-all       # 現在のゾーンのルール一覧
sudo firewall-cmd --add-port=7692/tcp --permanent && sudo firewall-cmd --reload

# どちらも使っていない場合（iptables / nftables）
sudo iptables -L INPUT -n --line-numbers
sudo nft list ruleset

ファイアウォールの許可は「ポート番号」だけでなく TCP か UDP かも合わせる必要があります。DNS（53）や WireGuard（51820）のように UDP を使うサービスは、53/udp のように明示します。

5. 別のホストからだけ届かない（クラウドのセキュリティグループなど）

ホスト側で待ち受けもファイアウォールも問題ないのに、インターネット越しや別のサブネットからだけ届かないときは、ホストの外側で止まっています。確認の観点を表にします。

切り分けの順番は「近いところから」です。同じホストの 127.0.0.1 → 同じホストの自分の IP → 同じネットワークの別ホスト → 外のホスト、と1段ずつ遠ざけると、どこで止まったかが特定できます。

よくある質問

Q. 80 と 8080 の違いは何ですか？ A. どちらも HTTP ですが、80 は IANA が HTTP に割り当てた標準ポート、8080 は「80 の代替（http-alt）」として登録された番号です（どちらも /etc/services で確認）。ブラウザは http://example.com/ のとき自動的に 80 につなぎますが、8080 を使うには http://example.com:8080/ と明示します。8080 がよく使われる理由は、1024 以上なので管理者権限なしで待ち受けられることと、80 を使う Web サーバー（nginx や Apache）と同居できることです。

Q. 443 と 80 はどう使い分けますか？ A. 443 は TLS で暗号化した HTTPS、80 は暗号化しない HTTPです。現在の Web は 443 が基本で、80 は「http:// で来たアクセスを https:// に転送（301 リダイレクト）するため」に残しておく構成が一般的です。両方を公開し、80 では転送だけを行うようにすると、以前のリンクや手入力のアクセスも安全な側に誘導できます。なお 443 の UDP は HTTP/3（QUIC）用で、/etc/services にも https 443/udp # HTTP/3 として登録されています。

Q. 445・3389・6379・27017 をインターネットに公開しないのはなぜですか？ A. これらは SMB（445）、RDP（3389）、Redis（6379）、MongoDB（27017）という「内部ネットワークで使う前提」のサービスだからです。ファイル共有やデータベースは、認証や暗号化を Web のように「不特定多数からのアクセス」向けに設計していないものが多く、公開すると不特定の接続試行を受け続けることになります。Redis の設定ファイルが既定で bind 127.0.0.1 -::1（自分自身のみ）になっているのも同じ考え方です。外から使いたいときは、VPN や SSH ポートフォワード（ssh -L 6379:127.0.0.1:6379 サーバー）で届かせるか、クラウドのセキュリティグループで送信元 IP を絞ると、公開範囲を広げずに済みます。

Q. 1024 未満のポートを使うには管理者権限が必要ですか？ A. Linux では必要です。 一般ユーザー（この環境では nobody）で python3 -m http.server 80 を実行すると PermissionError: [Errno 13] Permission denied になり、同じユーザーでも 1024 以上の 7695 番なら起動できました。境界の値は /proc/sys/net/ipv4/ip_unprivileged_port_start（この環境では 1024）で決まります。

runuser -u nobody -- python3 -m http.server 80            # 一般ユーザーで 80 番
runuser -u nobody -- python3 -m http.server --bind 127.0.0.1 7695   # 同じユーザーで 7695 番
cat /proc/sys/net/ipv4/ip_unprivileged_port_start

…（省略）…
    self.socket.bind(self.server_address)
PermissionError: [Errno 13] Permission denied
Serving HTTP on 127.0.0.1 port 7695 (http://127.0.0.1:7695/) ...
1024

対処は、sudo で起動する、setcap 'cap_net_bind_service=+ep' 実行ファイル で権限を付ける、または 8080 などで起動して nginx などのリバースプロキシで 80 から転送する、の3通りです。開発では 8080・3000・8000 を使い、本番だけリバースプロキシで 80/443 に出す構成が扱いやすいです。

まとめ

• ポート番号は 0〜65535 の「部屋番号」で、IP アドレスと組み合わせて宛先が決まる。 TCP と UDP で番号空間は別（同じ 7697 を両方で待ち受けられることを確認）
• IANA の3区分は 0〜1023（well-known／システム）、1024〜49151（ユーザー）、49152〜65535（動的）。 Linux のエフェメラル範囲は 32768〜60999（ip_local_port_range で確認）
• まず覚える番号は 22 SSH、25/465/587 SMTP、53 DNS、80 HTTP、443 HTTPS、3306 MySQL、5432 PostgreSQL、6379 Redis、8080 HTTP 代替、27017 MongoDB
• 待ち受けの確認は ss -tulnp、特定ポートは ss -tlnp 'sport = :番号' か lsof -i :番号、届くかは nc -zv と curl -v（コマンドが無ければ bash の /dev/tcp）
• 止めるときは PID を特定して kill PID。 名前での一括停止は使わない
• Connection refused は「届いたが待ち受けがない」、timed out は「届いていない」。 127.0.0.1 と 0.0.0.0 の違いは ss の Local Address 列で見分ける
• データベース・キャッシュ・リモートデスクトップ・ファイル共有は内部限定が基本。 外から使うなら VPN・SSH フォワード・送信元 IP 制限を挟む

参考（出典）

今回実際に開いて確認したページです。

• RFC 6335（IANA のポート番号の3区分、Section 6 / 8.1.2）：https://www.rfc-editor.org/rfc/rfc6335
• MongoDB「Default MongoDB Port」（27017〜27020）：https://www.mongodb.com/docs/manual/reference/default-mongodb-port/
• Kubernetes「Ports and Protocols」（6443、2379〜2380、10250、10256、10257、10259、30000〜32767）：https://kubernetes.io/docs/reference/networking/ports-and-protocols/
• Redis「Redis configuration」（--port 6380 --replicaof 127.0.0.1 6379 の例）：https://redis.io/docs/latest/operate/oss_and_stack/management/config/
• Redis 8.0 の redis.conf（「default is 6379」、bind 127.0.0.1 -::1）：https://raw.githubusercontent.com/redis/redis/8.0/redis.conf
• Apache Kafka「Quickstart」（--bootstrap-server localhost:9092）：https://kafka.apache.org/quickstart
• Prometheus「Getting started」（localhost:9090）：https://prometheus.io/docs/prometheus/latest/getting_started/
• Grafana「Configure Grafana」（http_port 既定 3000、http_addr）：https://grafana.com/docs/grafana/latest/setup-grafana/configure-grafana/
• Elasticsearch「Networking settings」（http.port 9200-9300、transport.port 9300-9400、network.host _local_）：https://www.elastic.co/docs/reference/elasticsearch/configuration-reference/networking-settings
• IANA「Service Name and Transport Protocol Port Number Registry」（今回は未閲覧。/etc/services の冒頭コメントに記載された更新元）：https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml

/etc/services の確認は Ubuntu 24.04.4 LTS（netbase 6.4、361 行）で行いました。

株式会社RJCでは、ポート番号の一覧や確認コマンドのようなネットワークの基礎を仲間と学び合っています。こうした知識を共有しながら、日々技術を磨いています。

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。