WindowsでWinError 10022が出る原因とポート80 bindの論点整理

本記事が扱う事象は、Windows上でPythonのsocketを使い、ポート80へbind（バインド）しようとした際に「WinError 10022」が発生するケースです。対象となる状況としては、Web通信に関するRAW（生）レベルのTCPパケットを取得したい意図が併記されることが多く、そこで「待受（サーバ）」と「監視（キャプチャ）」が同一視されやすい点が論点になります。そうすることによって、エラーの原因が「権限」なのか「API上の制約」なのか「ソケット状態」なのかが混線し、整理が難しくなります。 (Reddit)

• WinError 10022はWSAEINVALであり「引数か状態」の問題として現れる
• 「ポート80にbind」の目的が待受と監視で分かれる
• RAWソケットの制約でIPPROTO_TCPのbindが禁止される場合がある
• 10022周辺で分岐する確認点を「状態・権限・競合」で整理する
• パケット取得はNpcap等の方式があり、待受設計と分離される

WinError 10022はWSAEINVALであり「引数か状態」の問題として現れる

WinError 10022はWSAEINVAL（無効な引数）で、指定した値や呼び出し順が前提と合わないときに返り得ます。

WindowsのソケットAPI（Winsock）において10022は、Invalid argument（無効な引数）として定義されています。ここで言う「引数」は、アドレスやポート番号だけではなく、アドレスファミリ（AF_INETなど）・ソケット種別（SOCK_STREAM/ SOCK_RAWなど）・プロトコル（IPPROTO_TCPなど）の組み合わせも含みます。つまり、数値が範囲内でも、組み合わせが許可されない場合に同じコードが返る余地があります。 (Microsoft Learn)

ただし、WSAEINVALは「状態」を示すこともあります。典型例として、listen（リッスン）前にaccept（アクセプト）を呼ぶなど、ソケットの手順が前提と一致しない場合に10022になることが知られています。言い換えると、bindの失敗に見えても、直前の呼び出しや生成方法が原因である可能性が残ります。 (Stack Overflow)

以上を踏まえると、10022は「ポート80が悪い」と断定できる種類のエラーではありません。そのため、本記事の対象テーマでは、まず“何のためにbindしているのか”を分解し、API上の前提と照合する整理が必要になります。

「ポート80にbind」の目的が待受と監視で分かれる

ポート80へのbindは通常「HTTP待受」を意味しますが、パケット監視の目的とは機能が一致しません。

ポート80はHTTPで使われる代表的な番号であり、bindは「そのポートで接続を受ける」動作を成立させる手続きです。一方で、Web閲覧で発生する通信のパケットを取得したい場合、必要なのは“他の通信を横から読む”仕組みであり、特定ポートで待受を作ることとは別の層の話になります。そこで、意図が「監視」なのに実装が「待受」へ寄ると、設計がズレたまま原因探索が進みます。 (Reddit)

ただし、監視でも「ローカルのインターフェースへbindする」という言葉が使われる場合があります。たとえばRAW socket（RAWソケット）で特定のインターフェースに結び付ける操作があり、これが“ポート80へbind”という表現と混ざりやすい点が実務上の確認点となります。そうなると、同じbindでも「TCPサーバとしてのポート指定」なのか「RAWソケットのインターフェース指定」なのかで、前提条件が変わります。

つまり、ポート80という数字よりも、ソケット種別とプロトコル、そして取得対象（受信データか、通過パケットか）を先に確定させることが、論点整理の中心になります。次章では、監視側で使われがちなRAWソケットの制約を、Windows固有の仕様として整理します。

RAWソケットの制約でIPPROTO_TCPのbindが禁止される場合がある

WindowsではRAWソケットでIPPROTO_TCPを指定したbindが許可されない、という仕様上の制約があります。

Microsoftのドキュメントでは、RAWソケットに関する制限として「TCPデータをRAWソケットで送れない」ことに加え、「RAWソケットでIPPROTO_TCPを指定したbind呼び出しは許可されない」旨が明記されています。そうすることによって、TCPを“生のパケットとして扱う”設計を、OS側が制限する形になります。 (Microsoft Learn)

この制約は、ソケット生成時にSOCK_RAWとIPPROTO_TCPを組み合わせる場合に表面化しやすく、結果としてWinError 10022が出る例が報告されています。つまり、コード上はポート番号を正しく入れていても、Windowsの前提が満たされないために「無効な引数」として扱われる構造です。 (Stack Overflow)

なお、RAWソケットを使った受信全体の取得では、SIO_RCVALL（全受信）といったIOCTL（入出力制御）を使う方式もありますが、これも管理者権限が必要とされています。ここでのポイントは、制約が“実装ミス”ではなく“仕様としての許容範囲”に置かれている点です。次章では、10022の周辺で混同されやすい確認点を、待受・監視の双方からまとめます。 (Microsoft Learn)

10022周辺で分岐する確認点を「状態・権限・競合」で整理する

10022の周辺では、ソケット状態・管理者権限・既存プロセスの競合が別ルートで交差します。

WSAEINVALは状態不整合でも出るため、待受型の実装では「bind→listen→accept」という順序が崩れると10022になり得ます。これはポート80に限らず起こり、原因が“番号”ではなく“状態遷移”にある点が判断材料として重要であると整理できます。 (Stack Overflow)

一方で、監視型の実装では管理者権限の有無が関わります。SIO_RCVALLはAdministrator privilege（管理者権限）が必要とされ、一般ユーザー権限では実行条件差が生じる可能性があります。ここで、権限不足は10013（アクセス拒否）になる例もあるため、10022だけで権限問題と断定できない点が追加確認が必要となります。 (Microsoft Learn)

要点を整理すると、確認いの切り口は次のように分けられます。

ただし、競合は一般に別のエラー（例：アドレス使用中）で出ることが多く、10022とは直結しない場合があります。つまり、10022が出ているなら、競合よりも「RAW制約」か「状態」を優先して切り分ける、という構造が読み取れます。

なお、監視目的で「全パケット取得」を狙う場合、次の整理も併用されます。

この結果、ポート80へbindする行為が「待受の設計」なのか「監視の設計」なのかを先に確定しないと、切り分け軸が成立しません。次章では、監視を実現する別方式を含め、設計分離の論点をまとめます。

パケット取得はNpcap等の方式があり、待受設計と分離される

Windowsでパケット取得を成立させる方式は複数あり、TCP待受（ポート80 bind）とは別設計として扱われます。

Windowsでネットワークの通過パケットを扱う手段としては、WinsockのRAW機能に加え、パケットキャプチャ用ドライバを使う方式が知られています。NpcapはWinPcap互換のPcap API（パケットキャプチャAPI）を提供するライブラリとして整理されており、Windows 10/11での利用も前提に置かれています。 (Npcap)

他方、WinsockのRAWソケットはOS側の制約が明確で、IPPROTO_TCPに関してはbindが禁止されるため、TCPの“生パケット”を前提にした設計と整合しないケースが出ます。言い換えると、目的が「Web通信の観測」でも、実装手段がWinsock RAWに固定されると到達できない要件が残ります。 (Microsoft Learn)

ただし、本記事の対象となる事象で重要なのは、方式選定の是非ではなく、原因が三層に分かれる点です。第一に、ポート80待受はサーバ機能であり、第二に、通過パケット取得は監視機能であり、第三に、WindowsはRAWソケットのTCP利用に仕様制限を置いています。そのため、10022が出た場面では「何を成立させたいのか」と「その手段がWindowsで許可されるか」を同じ軸で照合することが、論点整理として有効になります。

以上を踏まえると、WinError 10022は“ポート80の特別さ”だけで説明できず、ソケットの種類・プロトコル指定・権限・状態遷移を分けて扱う必要があります。そうすることによって、同じエラーコードでも原因候補が異なる、というWindows特有の構造が明確になります。