Comparison questionMedium~7 min

Interview question

What is Kestrel, and why might an ASP.NET Core application run behind IIS, Nginx, a cloud ingress, or another reverse proxy?

Kestrel and reverse proxy responsibilities in ASP.NET Core

Separates the ASP.NET Core HTTP server from proxy, TLS, load-balancing, process-management, and forwarded-header responsibilities.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Kestrel is ASP.NET Core's default cross-platform HTTP server. It listens for connections, parses HTTP, creates the request features exposed through HttpContext, and sends the application response. Kestrel can be exposed directly as an Internet-facing edge server, or it can run behind a reverse proxy; both are supported designs. A reverse proxy such as IIS, Nginx, YARP, or a cloud ingress can own the public address, TLS termination, host and path routing, load balancing, connection policies, and integration with platform process management. It then forwards requests to the application. I choose the topology from deployment needs rather than claiming that Kestrel is inherently unsafe without a proxy.

Full answer below

Practice focus

ASP.NET Core hosting, Kestrel, edge hosting, reverse proxies, TLS termination, process management, load balancing, host filtering, and forwarded headers.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Hosting questions reveal whether someone understands where an ASP.NET Core process ends and the network platform begins. Kestrel and a reverse proxy can both handle HTTP, but they do not have identical ownership.
Kestrel is ASP.NET Core's default cross-platform HTTP server. It listens for connections, parses HTTP, creates the request features exposed through HttpContext, and sends the application response. Kestrel can be exposed directly as an Internet-facing edge server, or it can run behind a reverse proxy; both are supported designs. A reverse proxy such as IIS, Nginx, YARP, or a cloud ingress can own the public address, TLS termination, host and path routing, load balancing, connection policies, and integration with platform process management. It then forwards requests to the application. I choose the topology from deployment needs rather than claiming that Kestrel is inherently unsafe without a proxy.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
Behind a proxy, the connection Kestrel sees is the proxy connection, so the original scheme and client address are not automatically trustworthy application values. Forwarded Headers Middleware must run early and trust only the actual proxy networks or addresses; otherwise HTTPS redirects, generated links, authentication callbacks, rate limits, and audit logs can be wrong or spoofable. Host filtering and direct-access rules also matter because Kestrel binds to an address and port rather than using host headers to share that listener among unrelated processes. Health checks, request-size limits, timeouts, and body buffering need clear ownership so proxy and application settings do not conflict unexpectedly.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
I also identify the concrete hosting model. With IIS in-process hosting, the application uses the IIS HTTP Server inside the worker process rather than Kestrel behind a loopback hop. With IIS out-of-process hosting, the ASP.NET Core Module manages and proxies to the Kestrel process. Containers often run Kestrel as the process server while an ingress or managed load balancer provides the external edge. I align TLS and certificate ownership, HTTP protocol support, keep-alive and request timeouts, upload limits, graceful shutdown, and observability across those hops. I test the deployed path, including spoofed forwarding headers and attempted direct access, because localhost behavior does not prove the trust chain. When incidents occur, I separate proxy-generated failures from application responses using status details, access logs, correlation propagation, backend health, and whether the request ever reached Kestrel and the ASP.NET Core pipeline.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Saying Kestrel can never be safely exposed directly.
Trusting forwarded headers from any caller.
Assuming IIS always proxies to a separate Kestrel process.
Configuring conflicting timeout or request-size limits without ownership.

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

The application can bypass the proxy while still trusting proxy headers.
All client addresses appear as the load balancer with no documented strategy.
TLS, health, and shutdown ownership differ across replicas.
Proxy failures and application failures cannot be distinguished operationally.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

Can Kestrel be used directly as an edge server?
What changes with IIS in-process hosting?
Why do forwarded headers form a security boundary?

Continue practice

Move to the linked follow-up, next path step, prerequisite, or deeper variant.

2 linked

Next interviewer turn

Continue the conversation with a linked follow-up drill.

Forwarded headers

Go deeper

Practice the next layer of the same subject.

Application host lifecycle

Opening drill

Comparison questionMedium~7 min

Interview question

What is Kestrel, and why might an ASP.NET Core application run behind IIS, Nginx, a cloud ingress, or another reverse proxy?

Kestrel and reverse proxy responsibilities in ASP.NET Core

Separates the ASP.NET Core HTTP server from proxy, TLS, load-balancing, process-management, and forwarded-header responsibilities.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

ASP.NET Core hosting, Kestrel, edge hosting, reverse proxies, TLS termination, process management, load balancing, host filtering, and forwarded headers.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Hosting questions reveal whether someone understands where an ASP.NET Core process ends and the network platform begins. Kestrel and a reverse proxy can both handle HTTP, but they do not have identical ownership.
Kestrel is ASP.NET Core's default cross-platform HTTP server. It listens for connections, parses HTTP, creates the request features exposed through HttpContext, and sends the application response. Kestrel can be exposed directly as an Internet-facing edge server, or it can run behind a reverse proxy; both are supported designs. A reverse proxy such as IIS, Nginx, YARP, or a cloud ingress can own the public address, TLS termination, host and path routing, load balancing, connection policies, and integration with platform process management. It then forwards requests to the application. I choose the topology from deployment needs rather than claiming that Kestrel is inherently unsafe without a proxy.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
Behind a proxy, the connection Kestrel sees is the proxy connection, so the original scheme and client address are not automatically trustworthy application values. Forwarded Headers Middleware must run early and trust only the actual proxy networks or addresses; otherwise HTTPS redirects, generated links, authentication callbacks, rate limits, and audit logs can be wrong or spoofable. Host filtering and direct-access rules also matter because Kestrel binds to an address and port rather than using host headers to share that listener among unrelated processes. Health checks, request-size limits, timeouts, and body buffering need clear ownership so proxy and application settings do not conflict unexpectedly.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
I also identify the concrete hosting model. With IIS in-process hosting, the application uses the IIS HTTP Server inside the worker process rather than Kestrel behind a loopback hop. With IIS out-of-process hosting, the ASP.NET Core Module manages and proxies to the Kestrel process. Containers often run Kestrel as the process server while an ingress or managed load balancer provides the external edge. I align TLS and certificate ownership, HTTP protocol support, keep-alive and request timeouts, upload limits, graceful shutdown, and observability across those hops. I test the deployed path, including spoofed forwarding headers and attempted direct access, because localhost behavior does not prove the trust chain. When incidents occur, I separate proxy-generated failures from application responses using status details, access logs, correlation propagation, backend health, and whether the request ever reached Kestrel and the ASP.NET Core pipeline.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Saying Kestrel can never be safely exposed directly.
Trusting forwarded headers from any caller.
Assuming IIS always proxies to a separate Kestrel process.
Configuring conflicting timeout or request-size limits without ownership.

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

The application can bypass the proxy while still trusting proxy headers.
All client addresses appear as the load balancer with no documented strategy.
TLS, health, and shutdown ownership differ across replicas.
Proxy failures and application failures cannot be distinguished operationally.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

Can Kestrel be used directly as an edge server?
What changes with IIS in-process hosting?
Why do forwarded headers form a security boundary?

Continue practice

Move to the linked follow-up, next path step, prerequisite, or deeper variant.

2 linked

Next interviewer turn

Continue the conversation with a linked follow-up drill.

Forwarded headers

Go deeper

Practice the next layer of the same subject.

Application host lifecycle

What is Kestrel, and why might an ASP.NET Core application run behind IIS, Nginx, a cloud ingress, or another reverse proxy?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Next interviewer turn

Go deeper

What is Kestrel, and why might an ASP.NET Core application run behind IIS, Nginx, a cloud ingress, or another reverse proxy?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Next interviewer turn

Go deeper