ERR_TOO_MANY_REDIRECTS when accessing HA nodes directly

```
Product: PowerShell Universal
Version: 2026.1.6 (also 2026.1.3 before upgrade)
```

We have two nodes in HA. Connecting to SQL server on the back-end, as well as Azure Devops for the git sync. we have a single certificate that's on both nodes, as well as the load balancer.

What works: Accessing each endpoint locally via http(s)://localhost, or via the load balanced hostname.
What doesn't: Using each node's hostname, either locally on the server or from a different machine on the same network.

This is what's showing up in the browser's network calls.

There's also this filling up the log:
```
2026-05-13 11:28:07.368 +01:00 [INF][Microsoft.AspNetCore.Authentication.Negotiate.NegotiateHandler] Incomplete Negotiate handshake, sending an additional 401 Negotiate challenge.
2026-05-13 11:28:07.368 +01:00 [INF][Microsoft.AspNetCore.Hosting.Diagnostics] Request finished HTTP/1.1 GET https://SERVER_FQDN:5001/failed-login?error_id=225172db-fc68-43f5-88f2-0adb34037e51 - 401 0 null 0.4677ms
2026-05-13 11:28:07.372 +01:00 [INF][Microsoft.AspNetCore.Hosting.Diagnostics] Request starting HTTP/1.1 GET https://SERVER_FQDN/failed-login?error_id=225172db-fc68-43f5-88f2-0adb34037e51 - null null
2026-05-13 11:28:07.372 +01:00 [INF][Microsoft.AspNetCore.Hosting.Diagnostics] Request finished HTTP/1.1 GET https://SERVER_FQDN/failed-login?error_id=225172db-fc68-43f5-88f2-0adb34037e51 - 302 0 null 0.6914ms
2026-05-13 11:28:07.377 +01:00 [INF][Microsoft.AspNetCore.Hosting.Diagnostics] Request starting HTTP/1.1 GET https://SERVER_FQDN/failed-login?error_id=5a4214e0-5a25-4cf5-a155-b7e2c85ef7d2 - null null
```

Edge gives you an option to delete cookies when you receive the error, and on doing so it shows a PSU error page with the following:
```
An anonymous request was received in between authentication handshake requests.
Authentication configuration is invalid. Please contact your administrator.
```
Refreshing after this has no effect.

Both the servers and load balanced address are the same domain.

I've tried changing ports, changing the wildcard for kestrel in appsettings to be a hostname (that just breaks it in other ways) and adding CORS exceptions to no avail.
You get a basic auth prompt if in incognito or standard http, but that's the same result as above after filling out the credentials.

We have a legacy Universal server on version 3.x which doesn't have the same issue with direct access. That server's in the same Active Directory OU, with the same policies. It's a 2016 server however, and the new ones are 2022.

Right now it feels like either I've missed something in the configuration, or the OS is behaving differently with the auth requests. Hopefully someone has some insight they can shed on this...

TIA

@lloydmitchell

I am looking into this to see if I can help. This is to acknowledge your post. I'll have an update within 24 hours. In the meantime, although you've provided plenty of information, if you have any more you can provide that may be helpful down the line. The more information/logs that are presented, the better.

Thank you!

Ok, another interesting one we just discovered.

We changed the DNS entry for the load balanced IP to instead point to one of the nodes. After waiting for that to update, it worked flawlessly; accessing a single node directly via the load-balanced address is successful.

Could this be certificate related? The CN of the cert is the load balanced hostname, and both nodes have been added as SANs (DNS Name= fqdn.of.server).