System.Net.Http.HttpRequestException: No connection could be made because the target machine actively refused it. (127.0.0.1:15899) means nothing is listening on the host and port in brackets. Either the API is not running, or it runs on a different port from the one your client calls.

Start the API, read the port it prints in Now listening on, and make the client's base address use that exact scheme, host and port. netstat tells you in one line whether anything is listening at all.

The error

Unhandled exception. System.Net.Http.HttpRequestException: No connection could be made because the target machine actively refused it. (127.0.0.1:15899)
 ---> System.Net.Sockets.SocketException (10061): No connection could be made because the target machine actively refused it.
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.ThrowException(SocketError error, CancellationToken cancellationToken)
   ...
   at System.Net.Http.HttpConnectionPool.ConnectToTcpHostAsync(String host, Int32 port, HttpRequestMessage initialRequest, Boolean async, CancellationToken cancellationToken)

It came from a console client whose base address pointed at a port where nothing ran:

using var client = new HttpClient { BaseAddress = new Uri("http://127.0.0.1:15899/") };
var order = await client.GetFromJsonAsync<Order>("api/orders/1");

Why it happens

Socket error 10061 is Windows saying that the TCP connection reached the machine and the machine answered that no program accepts connections on that port. It is an answer, not a timeout, and the inner SocketException (10061) is the same code psql and other clients show for the same situation. The address in brackets at the end of the message is the one your code tried, so compare it with the address the API prints when it starts.

The usual mismatch is the port. dotnet new web writes ports into Properties/launchSettings.json for each new project (this one got http://localhost:5048 and https://localhost:7070), so a client copied from another project, or an API started with --urls or a different profile, leaves the two sides on different ports. Refusal on Windows is not instant either: the call failed after 2.1 s with 127.0.0.1 in the URL and after 4.2 s with localhost.

The fix

Check whether anything listens on the port the client uses:

netstat -ano | findstr ":15899"

It printed nothing, so nothing listened there. With the API started on its real port, the same check on that port showed the listener and its process id: 

info: Microsoft.Hosting.Lifetime[14]
      Now listening on: http://127.0.0.1:15810
  TCP    127.0.0.1:15810        0.0.0.0:0              LISTENING       40060

Then point the client at that address:

using var client = new HttpClient { BaseAddress = new Uri("http://127.0.0.1:15810/") };
var order = await client.GetFromJsonAsync<Order>("api/orders/1");

It printed Order { Id = 1, Customer = Maria Garcia, Total = 42.50 } in 0.2 s. Keep the base address in configuration rather than in code, so the client and the API's launch profile can be changed together.

How it was reproduced

A console client (dotnet new console, no packages) and an empty web API (dotnet new web) started with --urls http://127.0.0.1:15810, on .NET SDK 10.0.403 with runtime 10.0.14, on Windows 11. The client first called port 15899, where nothing ran, once with 127.0.0.1 and once with localhost. Ports, the record and the names are the test's own.

Frequently asked

What does SocketException 10061 mean in .NET?
Connection refused: the machine was reached, but no program listens on that port. Start the server, or change the client to the port the server actually listens on.
How do I check which port my ASP.NET Core API is listening on?
Read the Now listening on line the app prints at startup, or run netstat -ano and filter by the port with findstr. The last column is the process id of the listener.
Why does actively refused take two seconds on Windows?
In the test the refusal arrived after 2.1 s with 127.0.0.1 in the URL and after 4.2 s with localhost. The wait is Windows reporting the refused connection, not the server being slow; nothing was listening at all.

The same code 10061 from psql is in Connection refused (0x0000274D/10061), and which port an ASP.NET Core app really uses is in Kestrel ports and URLs, tested. More decoded errors in the Fixes category.