先に要点
- プロトコル は、コンピューター同士がやり取りするときの「ルール」です。何語で、どんな順番で、どう確認しながら話すかを決めておくものに近いです。
- HTTP、HTTPS、DNS、TCP、UDP は全部「役割の違うプロトコル」です。Webアクセス1回でも、これらが重なって動いています。
- 「APIにつながらない」を直すコツは、DNS → TCP → TLS → HTTP の「どの層で止まっているか」を
nslookup/nc/curl -vで1層ずつ確認することです。 - 「ポートは開けたのに動かない」は、プロセス未起動・バインドアドレス・ファイアウォールの3つで起きがちです。原因ごとに確認コマンドが違います。
「プロトコルって結局なんなのか、毎回ふわっとする」という人はかなり多いです。 HTTP や TCP の記事は読めても、「そもそもプロトコルって何のこと？」が曖昧なままだと、あとで用語が全部ばらばらに見えやすくなります。
この記事では、MDN の Protocol 用語解説、Cloudflare の protocol / Internet Protocol 解説を確認しながら初心者向けに整理しつつ、後半では「APIにつながらないときに、どの層を、どのコマンドで切り分けるか」まで実務寄りに踏み込みます。 通信そのものの違いを詳しく見たい場合は、TCPとUDPの違いは？実務で重要な使い分けを初心者向けに解説 もあわせて読むとかなりつながりやすいです。
まず、プロトコルって何？
一言でいうと、プロトコル は「やり取りのルール」です。 コンピューター同士が通信するとき、何もルールがなければ、送ったデータを相手が正しく読めません。
たとえば人間でも、
- 何語で話すか
- 先に誰が話すか
- 返事はどう返すか
- 途中で聞こえなかったらどうするか
が揃っていないと会話になりにくいです。 コンピューター同士も同じで、「どんな形式で送るか」「どう確認するか」を決めたルールが必要です。
MDN でも、プロトコルは「データ交換の形式を定義するルールの体系」と整理されています。 まずは「通信のマナー」ではなく、「通信の約束事」くらいで覚えると入りやすいです。
なんでプロトコルが必要なのか
理由はシンプルで、ルールがないと相手が理解できないからです。
たとえば、あるサーバーにアクセスしたときに、
- どこへ接続するのか
- 何を要求しているのか
- データをどう返すのか
- エラーのときどう知らせるのか
が決まっていないと、通信は成立しません。
つまり、プロトコルは「通信できるようにする最低限の共通ルール」です。 インターネットが世界中の機器で動いているのも、共通のプロトコルがあるからです。
身近な例でいうとどんな感じか
たとえで整理すると、かなり分かりやすくなります。
言語のルール
日本語で話すのか、英語で話すのかが決まっていないと会話しにくいです。プロトコルも、まず「どうやってやり取りするか」を決めています。
宅配のルール
住所、宛名、送り方、受け取り確認が決まっているから荷物が届きます。通信でも、順番や確認方法が決まっていないと届いたか分かりません。
会議の進め方
誰が最初に話すか、質問はいつするか、議事録をどう残すかが決まっていると進めやすいです。プロトコルも、やり取りの手順をそろえるためのものです。
代表的なプロトコルをざっくり見る
ここで一気に全部覚える必要はありません。 まずは「役割が違うルールがいくつもある」と押さえるだけで十分です。
| プロトコル | ざっくり何をするか | よく使うポート | よく出る場面 |
|---|---|---|---|
| HTTP | Webでリクエストとレスポンスをやり取りする | 80 | Webサイト、API |
| HTTPS | HTTP を TLS で暗号化して安全にやり取りする | 443 | ログイン、決済、ほぼすべてのWeb |
| DNS | 名前から接続先(IPアドレス)を調べる | 53 | ドメイン名の名前解決 |
| TCP | 順番や再送を見ながら確実に届ける | (上位が使う) | Web、SSH、業務通信 |
| UDP | 軽く素早く流す(届いたか保証しない) | (上位が使う) | DNS、音声、映像、一部ゲーム |
ここで大事なのは、「プロトコル = ひとつのもの」ではないことです。 役割ごとに違うプロトコルがあり、組み合わせて使われています。ポート番号も「公式に割り当てられた標準値」であって絶対ではなく、設定次第でズラせる点も後で効いてきます。
HTTPやTCPも、みんなプロトコル
ここは初心者がかなり混ざりやすいところです。
つまり、全部「プロトコル」ですが、担当が違います。 ここを「HTTP と TCP は別ジャンルの話」と見てしまうと、あとで混乱しやすいです。
たとえば Web サイトを 1 回見るときも、内部では次のように複数のプロトコルが重なって動いています。
この「DNS → TCP → TLS → HTTP」という順番が、そのまま次のトラブル切り分けの順番になります。
「APIにつながらない」を層で切り分ける
実務で「プロトコルを意識すると強い」と言われる一番分かりやすい場面が、ここです。 「APIにつながらない」を「全部ネットワークの問題」と雑に見るより、上の 4 段のどこで止まっているかを下から(または名前解決から)順に潰すと、原因にたどり着くのが圧倒的に速くなります。各層の確認コマンドはこうなります。
レイヤー1: DNS で名前が引けているか (nslookup / dig)
まず、ドメイン名が IP アドレスに変換できているかを見ます。
nslookup api.example.com正常なら、こんな出力になります。Address 行に IP が出ていれば名前解決は成功です。
Server: 192.168.1.1
Address: 192.168.1.1#53
Non-authoritative answer:
Name: api.example.com
Address: 93.184.216.34ここで次のような出力が出たら、DNS の段階で止まっています。HTTP やアプリのコードを疑う前に、ここで止まります。
| 出力 | 意味 | よくある原因 |
|---|---|---|
** server can't find api.example.com: NXDOMAIN |
そのドメインは存在しない | ドメイン名のタイプミス、レコード未作成、レコード削除直後 |
** server can't find api.example.com: SERVFAIL |
権威サーバーへの問い合わせに失敗 | 権威DNSの障害・設定ミス、DNSSEC検証失敗 |
;; connection timed out; no servers could be reached |
そもそもDNSサーバーに届いていない | ネットワーク未接続、社内DNS/VPN未接続、53番ブロック |
Linux / macOS なら dig api.example.com +short の方が出力が短く、スクリプトにも組みやすいです。IP が 1 行返れば成功、何も返らなければ名前解決に失敗、と読みます。
レイヤー2: TCP でポートまで届くか (nc / telnet)
名前が引けたら、次は「そのIPの該当ポートまでパケットが届くか」を見ます。HTTPS なら 443、HTTP なら 80 です。
nc -zv api.example.com 443成功時の典型出力はこうです(succeeded や Connected が出れば通っています)。
Connection to api.example.com (93.184.216.34) 443 port [tcp/https] succeeded!ここで失敗するときは、メッセージが 2 種類に分かれます。この違いが切り分けの肝です。
Connection refused(即座に拒否)
ポートまでは届いているが、そこで待ち受けているプロセスがいない状態。相手が「そのポートは空いてない」と即答している。アプリ未起動や、ポート番号の間違いが典型。
Connection timed out(無反応で待たされる)
パケットがファイアウォールやセキュリティグループで黙って捨てられている状態。返事自体が来ないので、ハングしてからタイムアウトする。経路上の遮断が典型。
nc が入っていない環境(特に Windows)では telnet api.example.com 443 でも代用できます。画面がクリア(またはカーソルだけ)になれば接続成功、すぐ 接続できませんでした と戻れば拒否、しばらく固まればタイムアウトです。待ち時間を区切りたいときは nc -zvw 5 api.example.com 443 のように -w でタイムアウト秒数を指定すると、判定が速くなります。
レイヤー3 / 4: TLS と HTTP まで見る (curl -v)
TCP が通ったら、あとは TLS ハンドシェイクと HTTP のやり取りです。ここは curl -v 1 本で両方まとめて見えます。
curl -v https://api.example.com/health出力は行頭の記号で読み分けます。* は curl 自身の情報(接続・TLS)、> は送ったリクエスト、< は返ってきたレスポンスです。
* Trying 93.184.216.34:443...
* Connected to api.example.com (93.184.216.34) port 443
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
> GET /health HTTP/1.1
> Host: api.example.com
< HTTP/1.1 200 OK
< content-type: application/jsonどこまで進んだかで原因がはっきり分かれます。
| どこで止まる / 何が出る | 層 | 見るべき原因 |
|---|---|---|
Could not resolve host |
DNS | レイヤー1に戻る(名前解決失敗) |
Connection refused / timed out |
TCP | レイヤー2に戻る(到達性・待ち受け) |
SSL certificate problem / handshake failure |
TLS | 証明書の期限切れ・名前不一致・中間証明書不足 |
HTTP/1.1 403 / 401 |
HTTP | 認証・APIキー・権限・WAFの設定 |
HTTP/1.1 502 / 503 / 504 |
HTTP | 上流(アプリ)の落ち・過負荷・タイムアウト |
ここまで来れば、「ネットワークが悪いのか、証明書が悪いのか、アプリが悪いのか」を、当て推量ではなくコマンドの出力で言い切れます。報告も「TCPは通るがTLSで証明書エラー、curlに SSL certificate problem: certificate has expired が出ています」のように具体的になり、対応が一気に進みます。
「ポートは開けたのに動かない」よくある3ケース
切り分けで一番ハマるのが、ここです。「ファイアウォールでポートを開けたはずなのに、まだ Connection refused や timed out が出る」というやつです。原因は大きく 3 つに分かれます。それぞれ 現象 → 原因 → 確認 → 回避 で整理します。
ケース1: プロセスがそもそも待ち受けていない
- 現象:
ncやcurlでConnection refusedが即座に返る。 - 原因: ファイアウォールは関係なく、そのポートで待ち受けるアプリ(プロセス)が起動していない、または別ポートで起動している。「拒否が即答で返る」のは、経路は通っているがポートが空いていない合図です。
- 確認: サーバー上で待ち受け一覧を見ます。
ss -ltnp(またはnetstat -ltnp、Windows はnetstat -ano)で、狙ったポートがLISTEN状態にあるかを確認します。出てこなければプロセスが上がっていません。 - 回避: アプリを起動する。
systemctl status myappでクラッシュしていないか、ログでポート競合(address already in use)が出ていないかも見ます。番号自体が違っていれば、設定ファイルの待ち受けポートを直します。
ケース2: バインドアドレスが 127.0.0.1 になっている
- 現象: サーバー内から
curl http://localhost:8080は 200 が返るのに、外部や別ホストからだけConnection refusedになる。 - 原因: アプリが
127.0.0.1(ループバック)だけにバインドしていて、外部NICからの接続を受けていない。開発用の初期設定でよくある状態です。 - 確認:
ss -ltnpのLocal Addressを見ます。127.0.0.1:8080だと内部限定、0.0.0.0:8080(または*:8080、IPv6 は:::8080)なら全インターフェースで待ち受けています。 - 回避: アプリの待ち受けアドレスを
0.0.0.0(全許可)や該当NICのIPに変更する。フレームワークなら起動オプション(例:--host 0.0.0.0)や設定のbind項目を直します。むやみに外へ開く前に、本当に外部公開してよいかも確認します。
ケース3: 経路上のファイアウォール / セキュリティグループで遮断
- 現象:
ncがConnection refusedではなくtimed outでハングする。サーバー内localhostへは通るのに、外からだけ無反応。 - 原因: サーバー自身のOSファイアウォール(
ufw/firewalld/ Windows Defender ファイアウォール)か、クラウド側のセキュリティグループ・ネットワークACLで、パケットが黙って破棄(DROP)されている。「無反応で待たされる=どこかで黙って捨てられている」が見分け方です。 - 確認: OS側は
sudo ufw status/sudo firewall-cmd --list-allで該当ポートの許可を確認。クラウドはコンソールでセキュリティグループのインバウンドルールに、対象ポートと送信元IPレンジ(例:0.0.0.0/0や社内IP)が入っているかを見ます。AWSなら戻りを自動許可する一方、ネットワークACLは戻り(エフェメラルポート)も明示許可が要る点に注意します。 - 回避: 必要なポートと送信元だけをインバウンド許可に追加する。多段(OSファイアウォール+セキュリティグループ+ロードバランサ)になっている構成では、どの段で落ちているかを上の
ncをサーバー間・外部から段階的に打って詰めると確実です。
「即拒否ならプロセス側、無反応ならファイアウォール側」という対応関係を覚えておくと、開けたつもりのポートのトラブルはかなり速く割れます。
そのほか実務で意識する場面
切り分け以外でも、プロトコルの理解はじわじわ効きます。
初心者がつまずきやすい誤解
プロトコル = 難しい専門用語ではない
もちろん技術用語ではあるのですが、意味としては「通信のルール」です。 最初から OSI 参照モデルや RFC を丸暗記しなくても、まずはこれで十分です。
HTTPだけがプロトコルではない
Web 系を触り始めると HTTP ばかり目に入るので、「プロトコル = HTTP」みたいに見えやすいです。 でも、実際は DNS も TCP も UDP も全部プロトコルです。
プロトコルひとつで通信が全部完結するわけではない
現実の通信は、ひとつのルールだけで動いているわけではありません。 複数のプロトコルが役割分担して動いています。だからこそ、トラブルも「どの層か」で切り分けられます。
まず何を覚えるとよいか
最初は、この3つで十分です。
- プロトコル = 通信のルール
- 役割ごとに違うプロトコルがある
- 実務では「どのプロトコルの話か(どの層か)」を分けられると強い
そのうえで、次に読むならこの順がかなり自然です。
- TCPとUDPの違いは？実務で重要な使い分けを初心者向けに解説
- WebSocketとは？HTTPとの違いとリアルタイム通信で使う場面を整理
- Webhookとは？APIとの違いと実務でよくある使い方をわかりやすく解説
- CORSとは？初心者がつまずきやすい原因と考え方をわかりやすく解説
プロトコルに関するよくある質問
Q. プロトコルと API は何が違いますか？
A. プロトコルは「通信のルール」そのもの、API は「そのルールに従ってアプリが提供する窓口」です。HTTP はプロトコル、REST API は HTTP の上に乗った API、という関係です。
Q. 「APIにつながらない」とき、最初にどのコマンドを打てばいいですか？
A. まず curl -v を 1 本打つのが速いです。Could not resolve host ならDNS、Connection refused / timed out ならTCP、SSL certificate problem ならTLS、HTTPステータスが出るならアプリ側、と最初の数行で当たりがつきます。そこから nslookup や nc -zv で該当層を深掘りします。
Q. Connection refused と Connection timed out は何が違いますか？
A. refused は「ポートまで届いたが待ち受けプロセスがいない」即答の拒否で、アプリ未起動やポート違いが典型です。timed out は「パケットが黙って捨てられて返事が来ない」状態で、ファイアウォールやセキュリティグループでの遮断が典型です。即拒否ならプロセス側、無反応ならファイアウォール側、と覚えると切り分けが速くなります。
Q. ポートを開けたのに curl が通らないのはなぜですか？
A. 多いのは3つです。(1) アプリが起動していない、(2) アプリが 127.0.0.1 だけにバインドしていて外から見えない、(3) OSファイアウォールやクラウドのセキュリティグループで遮断。ss -ltnp で待ち受けアドレスを、コンソールでインバウンドルールを確認すると切り分けられます。
Q. プロトコルは誰が決めていますか？
A. 多くは IETF が RFC という標準文書で定めています。Web 関連は W3C や WHATWG も関わります。エラーで迷ったら、対象プロトコルの RFC 番号から一次資料を当たると確実です。
Q. HTTPS は別のプロトコルですか？
A. 厳密には HTTP over TLS で、HTTP の通信を TLS で暗号化したものです。アプリから見ると HTTP と同じ使い方ができ、安全性だけ追加される、と考えると分かりやすいです。切り分けでも「TLSの層」と「HTTPの層」を別に見ると原因が割れやすくなります。
Q. プロトコルが古いとどうなりますか？
A. セキュリティ脆弱性、効率の悪さ、ブラウザのサポート終了などの問題が出ます。SSLv3、TLS 1.0/1.1、HTTP/1.0 はすでに非推奨で、現代では使われない設定が安全です。curl -v の SSL connection using ... 行で実際に使われたバージョンを確認できます。
まとめ
プロトコル とは、コンピューター同士がやり取りするときのルールです。 難しそうに見えますが、まずは「何語で、どんな順番で、どう確認しながら話すかを決めるもの」と考えれば十分です。
大事なのは、HTTP、HTTPS、DNS、TCP、UDP も全部「役割の違うプロトコル」だと分けて見られることです。
ここが分かると、「APIにつながらない」を DNS → TCP → TLS → HTTP の層に分け、nslookup / nc -zv / curl -v で 1 層ずつ確認して原因を言い切れるようになります。ネットワーク、Web、セキュリティの記事も、ここを軸にするとかなりつながりやすくなります。