Kestrel（ケストレル）とは？ASP.NET Core に入っているWebサーバー¶

2026-10-27 更新約9分で読めます

最終確認: 2026-10-27

30秒で復習¶

Kestrel（ケストレル）＝ASP.NET Core のアプリに最初から入っている、軽くて速いWebサーバー。 Windows・Linux・macOS のどれでも動く。名前は小さなハヤブサ（チョウゲンボウ）の英語名。
使い方は2通り：Kestrel だけでインターネットに直接出すか、前にリバースプロキシ（IIS・Nginx など）を置くか。社内システムでは後者が多い。
IIS と組み合わせるときは注意：既定の「インプロセス」では、アプリは IIS の中で動き、Kestrel は使われない。「アウトプロセス」のときだけ、IIS の後ろで Kestrel が動く。
リバースプロキシの後ろに置くときは、Forwarded Headers（本当の接続元IPと HTTPS かどうか）の設定を忘れない。
Windows のサービスとして動かすなら、実行アカウントに gMSA を使うと、パスワード管理がいらない。
覚え方：「アプリに付いてくる店員（Kestrel）と、店の入口の受付（IIS・Nginx）」

用語の正式名称と読み方¶

用語	意味
Kestrel	ケストレル。ASP.NET Core の標準のWebサーバー
ASP.NET Core	Microsoft の Webアプリ・API を作るための仕組み（.NET の一部）
リバースプロキシ	利用者からの通信をいったん受け取り、後ろのサーバーへ渡す中継役。IIS、Nginx、Apache、YARP など
ANCM	ASP.NET Core Module。IIS が ASP.NET Core のアプリを動かすための部品
インプロセス	アプリを IIS の作業プロセス（w3wp.exe）の中で動かす方式
アウトプロセス	アプリを別のプロセス（dotnet.exe）で動かし、IIS から Kestrel へ中継する方式
HTTP.sys	Windows だけで使える、もう1つの ASP.NET Core 用Webサーバー

質問：Kestrelとは？¶

答え： ASP.NET Core のアプリを作ると、最初から中に入っているWebサーバー。dotnet run でアプリを起動したときに、ブラウザからの通信を受け取っているのが Kestrel。IIS のように別にインストールするものではなく、アプリと一緒に配られる部品。

イメージ（たとえ話）¶

Kestrel＝アプリに付いてくる店員。注文（HTTPリクエスト）を受けて、料理（アプリの処理結果）を返すのは得意。
リバースプロキシ（IIS・Nginx）＝店の入口の受付。お客さんの確認、混雑の整理、複数のお店への案内、看板（証明書・HTTPS）の管理を引き受ける。
小さなお店なら店員だけでも回せる（Kestrel だけで公開）。大きな建物では、入口に受付を置くのが普通（リバースプロキシの後ろに置く）。

質問：どんな構成で使う？¶

答え： 「Kestrel だけで公開する」か「前にリバースプロキシを置く」かの2通り。

観点	Kestrel だけ（エッジ）	前にリバースプロキシ
構成のシンプルさ	◎ 部品が少ない	○ プロキシの設定が増える
1台で複数のアプリを 443 番で公開	△ 難しい	◎ ホスト名やパスで振り分けられる
HTTPS・証明書の管理	アプリごとに設定する	プロキシでまとめて管理できる
負荷分散・キャッシュ・WAF	別に用意する	プロキシの機能で足せる
よく使う場面	コンテナ（前にロードバランサーがある）、小さな社内ツール	社内のWindowsサーバー（IIS）、Linux サーバー（Nginx）

今の Kestrel は、インターネットに直接出しても使えるように作られている。ただ、証明書の管理や、複数アプリの同居をまとめたいので、プロキシを前に置くことが多い。
クラウドやコンテナでは、前にロードバランサー（Azure の Application Gateway、AWS の ALB など）があり、それがリバースプロキシの役をする。

質問：IISと組み合わせると、Kestrelは使われる？¶

答え： 設定による。既定（インプロセス）では使われない。 ここは勘違いしやすい。

方式	アプリが動く場所	使われるWebサーバー	特徴
インプロセス（既定）	IIS の作業プロセス（w3wp.exe）の中	IIS HTTP Server（Kestrel ではない）	中継がないので速い
アウトプロセス	別のプロセス（dotnet.exe）	Kestrel	IIS が受けた通信を Kestrel へ中継する

どちらにするかは、アプリの設定（プロジェクトファイルや web.config の hostingModel）で決まる。
「IIS で動かしているのに Kestrel の設定が効かない」ときは、インプロセスになっていないかを確認する。

質問：設定や運用で気をつけることは？¶

1. どこで待ち受けるか（エンドポイント）¶

appsettings.json で、待ち受ける URL と証明書を決められる。

{
  "Kestrel": {
    "Endpoints": {
      "Https": {
        "Url": "https://0.0.0.0:5001",
        "Certificate": { "Subject": "app.corp.example.com", "Store": "My", "Location": "LocalMachine" }
      }
    }
  }
}

プロキシの後ろに置くなら、Kestrel は http://localhost:5000 のようにサーバーの中からだけ受けるようにして、外からは直接つながらないようにする。

2. プロキシの後ろでは Forwarded Headers を設定する¶

リバースプロキシを通ると、Kestrel から見た接続元はプロキシのIPになり、HTTPS もHTTP に見える。本当の情報は X-Forwarded-For（接続元IP）と X-Forwarded-Proto（https かどうか）に入ってくるので、Forwarded Headers ミドルウェアで読み取る。

設定しないと起きること	例
ログの接続元IPが、全部プロキシのIPになる	不正アクセスの調査ができない
HTTPS なのに HTTP と判断される	ログイン後のリダイレクトが http:// になって失敗する

信頼するプロキシを決めておく

X-Forwarded-For は誰でも偽装して送れる。信頼するプロキシのIP（KnownProxies）だけから受け取った値を使うように設定する。何でも信じると、接続元IPを偽装されてIP制限をすり抜けられる。

3. 制限値¶

設定	意味	ひとこと
`MaxRequestBodySize`	1回に受け取れるデータの大きさ	既定は約28.6MB。大きなファイルのアップロードでは見直す
`MaxConcurrentConnections`	同時に受ける接続の数	既定は上限なし。プロキシ側でも制限できる
`KeepAliveTimeout` など	接続を保つ時間	長すぎると、ぶら下がった接続でサーバーが疲れる

4. Windows のサービスとして動かす（gMSA と組み合わせる）¶

IIS を使わずに、Kestrel のアプリをWindows サービスとして動かすこともできる（UseWindowsService）。

サービスの実行アカウントに gMSA（例：CORP\svc-web$）を使えば、パスワードの管理がいらない。
そのアカウントで SQL Server に Windows 認証でつなげば、接続文字列にパスワードを書かなくてよい。
利用者を Windows 認証（Kerberos）でログインさせる場合は、Negotiate 認証のパッケージを使い、サービスのホスト名の SPN を gMSA に登録する。

具体例¶

場面	おすすめの構成
社内の Windows サーバーで業務アプリを公開する	IIS の後ろ（インプロセス）。証明書と Windows 認証は IIS でまとめる
Linux サーバーで API を公開する	Nginx の後ろに Kestrel。Forwarded Headers を設定する
コンテナで動かす	Kestrel だけ。前のロードバランサーで HTTPS を終える
夜間にだけ動く社内向けの小さな API	Windows サービスで Kestrel。実行アカウントは gMSA
社外から社内アプリを使わせたい	アプリは社内のまま、ZTNAのコネクタ経由で公開する

確認したいこと¶

社内の ASP.NET Core アプリは、IIS のインプロセス・アウトプロセス、Kestrel だけのどれで動いているか
リバースプロキシの後ろのアプリで、Forwarded Headers と信頼するプロキシが設定されているか
Windows サービスで動かしているアプリの実行アカウントは何か（gMSA に置き換えられるか）
大きなファイルを受け取るアプリで、MaxRequestBodySize を見直しているか