IIS forcibly terminates backend TCP connections (WinError 64) when reverse proxying to long-running Python server on Windows

Question

IIS forcibly terminates backend TCP connections (WinError 64) when reverse proxying to long-running Python server on Windows

Amjad Almaqbali 20

I am experiencing repeated and unexpected backend connection terminations when using IIS as a reverse proxy to a locally running Python web server on Windows.

Environment

Operating System: Windows (desktop/server)

Web Server: IIS

Reverse proxy to a backend service running on 127.0.0.1:8000

Backend application: Python web application (ASGI-based)

Python version: 3.13

The backend server is running normally and listening on the local interface

Problem Description

After the application runs for some time, IIS forcibly closes the backend TCP socket. When this happens, the Python server logs the following error:

OSError: [WinError 64] The specified network name is no longer available
Accept failed on a socket
Task exception was never retrieved

This is the web.config I currently use:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <remove name="StaticFile" />
      <add name="httpPlatformHandler" path="*" verb="*" modules="httpPlatformHandler" resourceType="Unspecified" />
    </handlers>
    <httpPlatform processPath="C:\Inetpub\vhosts\test.dmmn.com\httpdocs\env\Scripts\python.exe" 
	arguments="-m uvicorn backend.main:app --host 127.0.0.1 --port %HTTP_PLATFORM_PORT%" 
	stdoutLogEnabled="true" stdoutLogFile="C:\Inetpub\vhosts\test.dmmn.com\httpdocs\logs\stdout.log">
      <environmentVariables>
        <environmentVariable name="PYTHONPATH" value="C:\Inetpub\vhosts\test.dmmn.com\httpdocs" />
      </environmentVariables>
    </httpPlatform>
  </system.webServer>
  <system.web>
    <compilation tempDirectory="C:\Inetpub\vhosts\test.dmmn.com\httpdocs\tmp" />
  </system.web>
</configuration>

1 answer

Your answer

Answer 1

Tom Tran (WICLOUD CORPORATION) 3,930 Microsoft External Staff Moderator

Hi @Amjad Almaqbali , Thanks for sharing your details!

I took a closer look at the behavior you’re seeing where IIS suddenly closes the connection to your backend Python server and your logs show:

OSError: [WinError 64] The specified network name is no longer available

From what I can tell, this doesn’t point to an issue in your Python app. I believe what’s happening is that IIS is closing the backend TCP connection earlier than your ASGI server expects, so Uvicorn continues trying to use a socket that IIS has already dropped.

httpPlatformHandler will start your Python process and forward requests to it, but I think it’s important to note that it isn’t a full reverse proxy. It doesn’t give much control over backend connection lifetime, buffering, or long‑running async requests. Because Uvicorn often keeps connections alive longer than IIS’s defaults, IIS may decide that the backend request is “done” or “expired” and close the TCP connection:

IIS forwards the request to your Python backend correctly.
But if a connection stays open too long (long async work, idle period, or slow-running handler), I believe IIS may close it based on its internal timeout rules.
When IIS closes the socket, Uvicorn tries to continue using it, which triggers WinError 64.

I also don’t think this is a Uvicorn issue, it’s more about how IIS manages backend connections in this setup.

Perhaps you could try out these suggestions first:

1. Increase httpPlatformHandler timeout values

I think increasing values like processTimeout and startupTimeLimit helps IIS avoid treating the backend process as unresponsive. This can reduce early connection drops.

2. Consider using ARR + URL Rewrite instead of httpPlatformHandler

If you want a more stable reverse proxy layer inside IIS, I suggest looking at Application Request Routing (ARR) with URL Rewrite. ARR provides proper proxy features like connection lifetime control and health management. This is also reflected in Microsoft’s ARR troubleshooting and configuration documentation here:

https://learn.microsoft.com/en-us/iis/extensions/url-rewrite-module/reverse-proxy-with-url-rewrite-v2-and-application-request-routing

3. Use a dedicated reverse proxy if the setup allows it

If there’s flexibility, I think using NGINX or HAProxy in front of Uvicorn is usually the most stable approach. These tools handle long-lived keep-alive connections and async workloads much more predictably than IIS’s built-in forwarding.

Hope this helps! If you have any questions, please feel free to comment below. I'll be happy to assist!

Amjad Almaqbali 20 Reputation points

2026-02-04T06:41:22.34+00:00

Thank you Tom so much for your response.

I have a question: Is there a better way to run this app rather than using httpPlatformHandler ? what do you recommend ??

Thanks,
Tom Tran (WICLOUD CORPORATION) 3,930 Reputation points Microsoft External Staff Moderator

2026-02-04T07:34:58.49+00:00

Hi @Amjad Almaqbali ,

Thanks for getting back to me!

In my opinion, if you’re asking for a “better way” than httpPlatformHandler, it depends on what you want IIS to do for you.

httpPlatformHandler is still a valid option, Microsoft describes it as an IIS module that does process management for an HTTP listener and proxies requests to the process it manages.

For Python specifically, Microsoft’s guidance also lists HttpPlatformHandler as the recommended approach vs FastCGI and notes it “passes socket connections directly to a standalone Python process” (Python on IIS doc).

If your issue is long/slow requests, a common tweak is requestTimeout (default is 00:02:00), so if requests can exceed that, increasing it is worth trying first (config reference).

If you want a more traditional reverse proxy setup inside IIS, I’d recommend ARR + URL Rewrite and running Uvicorn as a separate Windows service/process you manage yourself. Microsoft’s reverse proxy walkthrough is here (ARR + URL Rewrite guide). The tradeoff is ARR focuses on proxying, while httpPlatformHandler also does process management (this distinction is discussed in this Microsoft Q&A thread too: Q&A link).

(Optional) Here’s a third‑party community post that can give you a better understanding: Stack Overflow.

Disclaimer: This is a non-Microsoft website. The page appears 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.

I hope this is helpful to you! If you have any questions, please feel free to comment below. I'll be happy to assist!
Tom Tran (WICLOUD CORPORATION) 3,930 Reputation points Microsoft External Staff Moderator

2026-02-09T08:45:36.9033333+00:00

Hi @Amjad Almaqbali ,

I'm just checking in to see if you still have any questions, please feel free to comment below. I'll be happy to help!
Amjad Almaqbali 20 Reputation points

2026-02-09T10:17:10.31+00:00

Hi Tom,

Thank you for checking in again. I tried requestTimeout and kept it to alwaysRunning mode. However, the issue still occur.

My app contains many asyncio.new_event_loop() and APSchedulers, so I paused all these and notice the issue disappeared. Currently I tried to run a seperate worker.py that handles these only, and seperate it from the uvicorn app. I am not sure if this a good practice for production app, but until now I did not face the issue.

If not resolved, then I will do this:
ARR + URL Rewrite and running Uvicorn as a separate Windows service/process you manage yourself.

Thanks for your support,

Regards,

Amjad
Tom Tran (WICLOUD CORPORATION) 3,930 Reputation points Microsoft External Staff Moderator

2026-02-09T10:48:15.75+00:00

Hi @Amjad Almaqbali ,

Thanks for the extra details! It's very helpful.

From my understanding, When APScheduler and those extra event loops run inside the same IIS‑managed process, IIS can still interrupt things during idle/recycle/shutdown events, which leads to the WinError 64 disconnect. When you moved that work into a separate worker.py, the issue stopped because the background tasks were no longer tied to IIS’s lifecycle.

So yes, running the scheduler/loops in a separate process is a totally valid production pattern on Windows. It keeps Uvicorn focused on HTTP only, and IIS won’t interfere with your background work anymore.

If you ever want even cleaner isolation, then your fallback (ARR + URL Rewrite + Uvicorn as a Windows service) is also a solid choice. But if the split you’re testing now is stable, it’s perfectly fine to keep it.

Share via

IIS forcibly terminates backend TCP connections (WinError 64) when reverse proxying to long-running Python server on Windows

Environment

Problem Description

1 answer

Your answer