Kestrel自托管SignalR的AspNetCore应用请求无响应问题求助

Hey there, let's troubleshoot this step by step—since your other IIS-proxied apps are running fine, we can narrow down the issue to your specific ASP.NET Core + SignalR stack rather than general IIS problems.

Start with the basics to rule out service-level failures:

• Open the Services console (services.msc) and confirm your Windows service is in a Running state. If it's restarting frequently, that's a clear sign of a crash on startup or runtime.
• Dig into your app's own logs: If you're using a logging framework like Serilog or NLog, check the output files for unhandled exceptions, startup errors, or SignalR-specific failures. For vanilla ASP.NET Core 2.0, default logs might be in the event viewer or a logs folder relative to your service executable.
• Check the Windows Event Viewer (under Windows Logs > Application) for error entries tagged with your service's name. Look for issues like Kestrel failing to bind to its port, permission denied errors, or runtime exceptions that crashed the process.

Since IIS acts as a proxy, let's isolate whether the problem is with the backend Kestrel app or the proxy layer:

• Find the port your Kestrel instance is configured to use (check appsettings.json for Kestrel endpoints, or your startup code where you configure Kestrel).
• On the server, use curl or a local browser to hit http://localhost:[your-kestrel-port]/[a-test-endpoint] (e.g., a simple API controller action that returns a 200 OK).
  • If this direct request fails: The issue is in your ASP.NET Core app/Kestrel. Move to the next section for deeper app-level checks.
  • If this direct request works: The problem is in the IIS proxy configuration—skip to section 3.

If Kestrel works directly but IIS doesn't pass requests through:

• Verify your IIS site's URL Rewrite rules: Open IIS Manager, go to your site, and check the rewrite rules. Ensure the rule is pointing to the correct Kestrel port, and there are no typos or recent changes that broke the proxy.
• Check the application pool for your IIS site: Even though other apps work, confirm the pool has permissions to communicate with the Kestrel port. Also, check if the pool is running under an identity that has access to your app's files (if using physical path mapping).
• Review IIS logs: Default logs live in %SystemDrive%\inetpub\logs\LogFiles\W3SVC[site-id]. Look for status codes like 502.5 (ASP.NET Core process failure) or 503 (service unavailable) to pinpoint proxy-level failures.

Since you're using SignalR 2.2.2 via Microsoft.AspNetCore.Owin, compatibility or middleware order issues could be the culprit:

• Check middleware order in your Startup.cs: Ensure the OWIN/SignalR middleware is registered before routing or other core ASP.NET Core middleware. Incorrect order can block requests from reaching SignalR hubs.
• Look for NuGet package conflicts: Did you recently update any packages (like ASP.NET Core runtime, OWIN, or SignalR)? Mismatched versions between ASP.NET Core 2.0 and older OWIN/SignalR libraries can cause runtime failures.
• Check SignalR-specific logs: Look for entries about hub initialization failures, WebSocket connection blocks, or timeout errors. SignalR is sensitive to connection issues, so even a small config change can break it.

• Open Task Manager and find your app's process (usually dotnet.exe or your custom service executable). Check for excessive CPU or memory usage—if it's pegged at 100% CPU, the app might be stuck in a loop or deadlock.
• Verify port ownership: Run netstat -ano | findstr :[your-kestrel-port] in Command Prompt. Make sure the PID matches your service's process—if another app is using the port, Kestrel can't bind to it.
• Check for file locks: If your app writes to logs or reads from config files, use a tool like Process Explorer to see if any files are locked by another process. A locked log file can cause the app to hang when trying to write.

Last but not least, think about what changed before the issue started:

• Did you deploy new code? Roll back to a known-good version to see if the problem goes away—this will confirm if it's a code-related issue.
• Were there Windows updates or .NET Core runtime updates installed? ASP.NET Core 2.0 is an older version, and recent runtime updates might introduce compatibility breaks.
• Did you modify any server settings (firewall, IIS config, service permissions)? Even a small change like a firewall rule blocking the Kestrel port can take down your app.

内容的提问来源于stack exchange，提问作者Beorn