IIS abruptly closes TCP connection when receiving a request with "Connection: close" header

Question

IIS abruptly closes TCP connection when receiving a request with "Connection: close" header

Laurens PLUMET 30

Yesterday I've updated Windows on my pc, I assume my IIS webserver also must have been updated. Before the update I could send requests to my IIS webserver with the "Connection: close" header and it would behave fine. Now it seems to abruptly close the connection (with an RST). The version of my IIS webserver is 10.0.26100.1.

I can easily reproduce this behavior with the following curl command: curl -v --http1.1 -H "Connection: close" http://localhost/.

Without the "Connection: close" header everything works as expected.

Some extra info, the site handling the request is an ASP.NET application using the DefaultAppPool with its original settings.

What could I possibly do to solve this issue?

Kind regards

Laurens

Tom Tran (WICLOUD CORPORATION) 4,860 Reputation points Microsoft External Staff Moderator

2026-03-13T07:27:46.1633333+00:00
Hi @Laurens PLUMET,

Since IIS relies on the Windows HTTP.sys driver to receive HTTP requests before they reach the IIS worker process, it would be helpful to confirm whether the request is actually reaching IIS or being reset earlier in the HTTP.sys layer.

Could you please check:

When you run the curl command, does the request appear in the IIS access logs?

Could you try the same request against a simple static file in IIS (for example /test.html) to see if the behavior is the same?

Also, since you mentioned the issue started after installing Windows updates, please confirm the exact Windows version/build (winver) and whether there are any pending updates.
Laurens PLUMET 30 Reputation points

2026-03-13T08:47:01.3366667+00:00

Hi @Tom Tran (WICLOUD CORPORATION)

Thanks for your prompt response.

I can confirm that this issue also occurs with a simple static test file. I've enabled failed request tracing for all requests and according to those logs everything works fine and the response I should receive is a 200 OK. But that's not what I see in the output of the curl (curl: (56) Recv failure: Connection was reset).

I've added these logs in case you would want to take a look at it, fr000001.xml.

My exact build version is 24H2 (OS Build 26100.8037). I do not see any pending updates but my machine but I must note that my pc is managed by our IT department and they could be withholding the latest updates (I'm currently verifying with them if this is the case).
Laurens PLUMET 30 Reputation points

2026-03-13T09:00:22.4466667+00:00

Excuse me Tom, I see I've added the wrong logs, fr000004.xml.

I do see something isn't going right in these logs, because of the BytesSent="0.
Laurens PLUMET 30 Reputation points

2026-03-13T09:06:40.8+00:00

I do not seem to get the BytesSent="0", ErrorCode="Access is denied. (0x80070005)" error when I do the following curl curl -v --http1.1 http://localhost:8080/test.html. I suppose the error is because the IIS is trying to write the the TCP stream which is already closed.

Answer accepted by question author

1 additional answer

Your answer

Tom Tran (WICLOUD CORPORATION) 4,860 Reputation points Microsoft External Staff Moderator

2026-03-13T07:27:46.1633333+00:00

Hi @Laurens PLUMET,

Since IIS relies on the Windows HTTP.sys driver to receive HTTP requests before they reach the IIS worker process, it would be helpful to confirm whether the request is actually reaching IIS or being reset earlier in the HTTP.sys layer.

Could you please check:

When you run the curl command, does the request appear in the IIS access logs?

Could you try the same request against a simple static file in IIS (for example /test.html) to see if the behavior is the same?

Also, since you mentioned the issue started after installing Windows updates, please confirm the exact Windows version/build (winver) and whether there are any pending updates.
Laurens PLUMET 30 Reputation points

2026-03-13T08:47:01.3366667+00:00

Hi @Tom Tran (WICLOUD CORPORATION)

Thanks for your prompt response.

I can confirm that this issue also occurs with a simple static test file. I've enabled failed request tracing for all requests and according to those logs everything works fine and the response I should receive is a 200 OK. But that's not what I see in the output of the curl (curl: (56) Recv failure: Connection was reset).

I've added these logs in case you would want to take a look at it, fr000001.xml.

My exact build version is 24H2 (OS Build 26100.8037). I do not see any pending updates but my machine but I must note that my pc is managed by our IT department and they could be withholding the latest updates (I'm currently verifying with them if this is the case).
Laurens PLUMET 30 Reputation points

2026-03-13T09:00:22.4466667+00:00

Excuse me Tom, I see I've added the wrong logs, fr000004.xml.

I do see something isn't going right in these logs, because of the BytesSent="0.
Laurens PLUMET 30 Reputation points

2026-03-13T09:06:40.8+00:00

I do not seem to get the BytesSent="0", ErrorCode="Access is denied. (0x80070005)" error when I do the following curl curl -v --http1.1 http://localhost:8080/test.html. I suppose the error is because the IIS is trying to write the the TCP stream which is already closed.

Answer 1

Tom Tran (WICLOUD CORPORATION) 4,860 Microsoft External Staff Moderator

Hi @Laurens PLUMET,

Thanks for checking that.

Your explanation makes sense. If the connection is already closed and IIS later tries to send the response, the trace can show BytesSent="0" with an error like 0x80070005. In this situation it usually just means IIS attempted to write to a connection that was already closed.

From your trace, we can see the request reaches IIS, the StaticFile handler is selected, and the request completes with 200. However, BytesSent="0" indicates the connection closed before IIS could send the response.

Since the request works normally without the Connection: close header, the IIS pipeline itself appears to be working correctly. The connection may be getting reset at the HTTP.sys / networking layer instead.

Could you please check whether anything appears in the HTTP.sys logs when the reset happens?

C:\Windows\System32\LogFiles\HTTPERR

If the machine is managed by your IT department, it would be great to confirm which Windows updates are installed. Some Windows 11 24H2 updates introduced issues in HTTP.sys that caused localhost/IIS connections to reset unexpectedly.

Laurens PLUMET 30 Reputation points

2026-03-13T10:24:07.8433333+00:00

Nothing seems to be written to the HTTPERR file when the reset happens... I'll confirm which Windows updates are installed as soon as I've had a response from our IT department.
Laurens PLUMET 30 Reputation points

2026-03-13T12:53:33.5033333+00:00

I've synced with our IT department, turns out I'm on the latest version of Windows and the cumulative update (KB5068861), which contains the fix according to Q&A Assist, is successfully installed...
Tom Tran (WICLOUD CORPORATION) 4,860 Reputation points Microsoft External Staff Moderator

2026-03-16T02:59:02.1666667+00:00
Hi @Laurens PLUMET,

Thanks for the confirmation.

Since your system is running a newer cumulative update (KB5079473), it should already include the fix that was previously released for the known HTTP.sys localhost issue like you said.

From the traces we reviewed earlier, the request successfully reaches IIS and is handled by the StaticFile handler with a 200 status. However, the FREB trace shows BytesSent="0", which indicates the connection is closed before IIS can send the response.

Since the request works normally when the Connection: close header is not present, this suggests the IIS request pipeline itself is working correctly and the behavior may be related to how the connection is being handled rather than an issue with IIS processing.

Could you perhaps try the same request using the IPv4 loopback address instead of localhost?

curl -v --http1.1 -H "Connection: close" http://127.0.0.1:8080/test.html
Laurens PLUMET 30 Reputation points

2026-03-16T07:00:17.2066667+00:00

Hi @Tom Tran (WICLOUD CORPORATION)

I've just executed to curl command with the IPv4 loopback address and it still failed.
Tom Tran (WICLOUD CORPORATION) 4,860 Reputation points Microsoft External Staff Moderator

2026-03-16T07:29:09.31+00:00
Hi Laurens,

Thank you for running the additional test and confirming that the behavior is the same when using 127.0.0.1. That helps rule out an IPv4/IPv6 resolution issue.

Since the request itself is processed successfully but the connection resets before the response is sent, the next step is to determine whether this behavior is triggered by the curl client or by something in the local networking environment.

Could you please try the following checks?

1. Try the request from a browser

Open a browser on the same machine and navigate to:

http://localhost:8080/test.html

If the page loads normally, it would indicate that the IIS site is responding correctly and that the reset may be related to how curl is handling the connection.

2. Try the request from PowerShell

Open PowerShell and run the following command:

Invoke-WebRequest http://localhost:8080/test.html

This uses a different HTTP client than curl. If this succeeds while curl fails, it would help confirm that the behavior may be client-specific.

3. Check whether any security or endpoint software is installed

If the machine has antivirus, endpoint protection, or network monitoring software installed, it may intercept or filter localhost traffic. In some cases these tools can terminate TCP connections before the response completes, which may result in connection reset errors such as the one curl reports.

If possible, please confirm whether any such software is present on the system.

Thank you again for the time you've spent testing this so far.
Laurens PLUMET 30 Reputation points

2026-03-16T08:28:20.9133333+00:00

Hi Tom,

These requests work, but they don't include the Connection: Close header, so the HTTP 1.1 default Keep-alive is used. When I specify the Connection: Close header in the invoke webrequest command (Invoke-WebRequest -Uri "http://localhost/" -Headers @{ "Connection" = "close" }) I receive the same error again...

About the antivirus, that is an interesting suggestion. I do have an antivirus installed which intercepts requests. I've requested our IT department to (temporarily) disable this on my machine. I will keep you posted when they have done so.
Tom Tran (WICLOUD CORPORATION) 4,860 Reputation points Microsoft External Staff Moderator

2026-03-18T09:44:16.1333333+00:00

Hi @Laurens PLUMET,

I'm just checking to if there is any updates on this.
Laurens PLUMET 30 Reputation points

2026-03-19T07:05:53.5866667+00:00

Hi Tom,

Sorry for the delay, the person of our IT department who handles these kinds of tickets has a week off. Since I've created a workaround myself for this issue, the internal ticket has been marked as non-urgent. I expect to be able to let you know more next week.
Tom Tran (WICLOUD CORPORATION) 4,860 Reputation points Microsoft External Staff Moderator

2026-03-19T07:10:56.8666667+00:00

Hi @Laurens PLUMET,

Thank you for the update of your situation. I appreciate it.

When you get the chance, please feel free to reach out whenever it works best for you.
Laurens PLUMET 30 Reputation points

2026-03-24T09:48:28.2266667+00:00

Hi @Tom Tran (WICLOUD CORPORATION)

I'm happy to inform you that disabling the antivirus (Sophos Endpoint Agent) on my machine prevents this issue from happening.

I really want to thank you for your patience and perseverance on this case.

Since we now know that the problem lies with a compatibility issue with Windows (update KB5079473) and my antivirus, would you perhaps have another, more targeted solution than disabling my antivirus?
Tom Tran (WICLOUD CORPORATION) 4,860 Reputation points Microsoft External Staff Moderator

2026-03-24T10:07:43.4566667+00:00

Hi @Laurens PLUMET,

Thank you for confirming this, that’s very helpful.

Since disabling the Sophos Endpoint Agent prevents the issue, this indicates that the connection reset is being triggered when Sophos is actively inspecting the traffic, rather than by IIS itself.

In this case, instead of disabling the antivirus entirely, I found that a more practical approach would be to try and configure an exclusion in Sophos so that this traffic is not intercepted. For example, this could include excluding IIS-related processes (such as w3wp.exe) or localhost traffic from inspection, depending on what options are available in your policy.

As this behavior appears to be specific to how Sophos is handling the connection (particularly when the Connection: close header is used), it would also be worth checking with your IT team or Sophos support to see if this is a known scenario or if there are recommended exclusions for it.

Disclaimer: These are non-Microsoft websites. The pages appear to be providing accurate, safe information. Watch out for ads on the site that may advertise products frequently classifies as a PUP (Potentially Unwanted Products). Thoroughly research any product advertised on the site before you decide to download and install it.

Please feel free to comment below if you still have any questions. I'll be happy to assist!

If you find my assistance helpful so far, I would greatly appreciate it if you could consider following this guidance to provide feedback.

Answer 2

The behavior matches a known issue introduced by a recent Windows Server 2025 / Windows 11 Server build security update that affects HTTP.sys. After the October security update, server-side applications that rely on HTTP.sys (including IIS 10) can have problems handling incoming connections, which can surface as IIS sites failing to load or connections being reset (RST) under certain conditions. A request with Connection: close is one of the patterns that can trigger the faulty behavior.

The issue is specifically called out for OS build 26100.x, which matches the IIS version 10.0.26100.1 in use. Microsoft has released an out-of-band update and then a subsequent cumulative update that address HTTP.sys/IIS connection problems.

To resolve the problem:

Open Settings → Windows Update on the affected machine.
Select Check for updates and install all available updates.
Restart the machine, even if no new updates appear to be installed.

If the problematic October security update is present, ensure that the later update containing the fix is installed. The documented fix for the HTTP.sys/IIS connection issue is included in a later cumulative update (KB5068861 for the affected OS build).

After applying the latest cumulative update and rebooting, IIS should stop resetting connections when handling requests that include Connection: close.

References:

Share via

IIS abruptly closes TCP connection when receiving a request with "Connection: close" header

1 additional answer

Your answer