Comparison questionMedium~7 minASP.NET Core Framework Essentials / 24 of 26

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 HTTP server: it accepts connections, parses HTTP, exposes the request through HttpContext, and sends the response. It may face the Internet directly or sit behind a reverse proxy. A proxy or cloud ingress can own the public endpoint, TLS termination, routing, load balancing, and edge connection policy. The right topology depends on the hosting environment.

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 HTTP server: it accepts connections, parses HTTP, exposes the request through HttpContext, and sends the response. It may face the Internet directly or sit behind a reverse proxy. A proxy or cloud ingress can own the public endpoint, TLS termination, routing, load balancing, and edge connection policy. The right topology depends on the hosting environment.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
Behind a proxy, Kestrel sees the proxy connection rather than the original client connection. Forwarded headers must therefore run early and trust only known proxies; otherwise scheme, client IP, redirects, authentication callbacks, and rate limits can be wrong or spoofed. Request limits, timeouts, health checks, and direct-access rules also need one clear owner across the hops.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
The advanced concern is the actual trust and failure boundary, not memorizing every hosting topology. I align TLS, forwarding, timeout, size-limit, and graceful-shutdown behavior across the edge and application. During an incident, proxy access logs and correlation tell me whether the request reached Kestrel before I investigate application code. I also test the deployed forwarding path and blocked direct access, because localhost behavior does not prove that boundary.

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 the section

Next in ASP.NET Core Framework Essentials: JSON Contract

Step 25 of 26

JSON serialization as an ASP.NET Core API contract

Practice route

Read core answer Review checklist Follow-up prompts Track progress

Finished this drill?

Practice freely. Sign in only when you want to save completion, confidence, notes, or bookmarks.

New to Aporeon? Create account

Drill details

Share the question with a concise Core-answer excerpt and invite other developers to add their perspective.

Was this drill useful?

Help improve the interview library.

Found this answer useful?

Say thanks with a standalone, one-time $5 contribution. No account required.

No subscription or perks.Choose another amount

Human editorial direction

Aporeon is shaped by Aleksandar Tomovski, a software developer with experience on both sides of technical interviews. Content is reviewed for accuracy, natural spoken delivery, useful depth, and honest trade-offs.

About the creator Editorial standards

Opening drill

Comparison questionMedium~7 minASP.NET Core Framework Essentials / 24 of 26

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 HTTP server: it accepts connections, parses HTTP, exposes the request through HttpContext, and sends the response. It may face the Internet directly or sit behind a reverse proxy. A proxy or cloud ingress can own the public endpoint, TLS termination, routing, load balancing, and edge connection policy. The right topology depends on the hosting environment.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
Behind a proxy, Kestrel sees the proxy connection rather than the original client connection. Forwarded headers must therefore run early and trust only known proxies; otherwise scheme, client IP, redirects, authentication callbacks, and rate limits can be wrong or spoofed. Request limits, timeouts, health checks, and direct-access rules also need one clear owner across the hops.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
The advanced concern is the actual trust and failure boundary, not memorizing every hosting topology. I align TLS, forwarding, timeout, size-limit, and graceful-shutdown behavior across the edge and application. During an incident, proxy access logs and correlation tell me whether the request reached Kestrel before I investigate application code. I also test the deployed forwarding path and blocked direct access, because localhost behavior does not prove that boundary.

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 the section

Next in ASP.NET Core Framework Essentials: JSON Contract

Step 25 of 26

JSON serialization as an ASP.NET Core API contract

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 the section

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 the section