Issue to access the server from the client

Question

Hi,

The project is running well on the server like

I get the issues like

The site could be temporarily unavailable or too busy. Try again in a few moments.

If you are unable to load any pages, check your computer’s network connection.

If your computer or network is protected by a firewall or proxy, make sure that Firefox is permitted to access the web.

by the following. Instead of myowndom.org, I used one valid domain.

https://myowndom.org:7060/swagger/index.html

Answer 1

Hi @Peter Liang ,

Thanks for reaching out.

When you run:

https://localhost:7060/swagger/index.html

that’s using the development profile on your machine. Port 7060 is just a random development port assigned by Kestrel/IIS Express. It does not automatically exist on your IIS server.

On your server, you mentioned IIS is bound to HTTPS on port 443. For HTTPS, port 443 is the default, so accessing:

https://abc.com/

is the correct way to test the deployment (no need to specify :443).

Now the key issue: in your Program.cs, Swagger is wrapped inside:

if (app.Environment.IsDevelopment())
{
    app.UseSwagger();
    app.UseSwaggerUI();
}

When you deploy to IIS, the environment is typically Production unless you explicitly changed ASPNETCORE_ENVIRONMENT. That means Swagger is not enabled on the server. So when you try:

https://abc.com/swagger/index.html

a 404 - File not found is expected. It’s not a connectivity failure, Swagger simply isn’t being served in Production.

Here’s how to move forward:

Step 1: Test basic deployment

Try accessing:

https://abc.com/

You mapped:

app.MapGet("/", () => "Hello world!");

If you see “Hello world!”, then:

• DNS is correct
• IIS binding is correct
• The site is deployed correctly
• Only Swagger is disabled

If that works, your server is fine.

Step 2: If you want Swagger in Production

Move Swagger outside the development check:

app.UseSwagger();
app.UseSwaggerUI();

Or temporarily set the environment variable on the server to Development (not recommended long-term for security reasons).

Step 3: If root URL fails

If https://abc.com/ does not return “Hello world!”, then the issue is with IIS configuration. In that case, verify:

• The IIS site is pointing to the correct published folder
• The App Pool is running
• DNS (nslookup abc.com) resolves to the correct server IP
• Firewall allows inbound 443

Hope this helps! If my answer was helpful - kindly follow the instructions here so others with the same problem can benefit as well.

Answer 2

Peter, this is a duplicate thread. Per Microsoft Q&A forum rules, please do not create multiple threads for the same issue. I am linking the original thread here so other community members can see the extensive troubleshooting already performed: https://learn.microsoft.com/en-us/answers/questions/5768993/port-issue

Regarding your screenshot: showing the application running on localhost:7060 only confirms it works in your local development environment. It has zero relevance to a remote deployment.

As explained previously, we cannot move forward without your remote server configuration. There is a fundamental disconnect here:

1. Development Ports: The port 7060 is a random assignment for your local machine's Kestrel/IIS Express profile. It does not automatically exist on a remote server.
2. IIS Bindings: If you want the application to run on a remote host, you must manually configure IIS Site Bindings and ensure the Firewall allows traffic on that specific port.
3. Environment Misalignment: You seem to believe that because the "client" is ready, the "server" must be as well. This is incorrect. If the service isn't listening on the remote IP at that specific port, the client will always fail.

Until you provide the remote IIS configuration and firewall status as requested multiple times, the community cannot fill the gaps in your deployment strategy.

Answer 3

Hi @Peter_1985 ,

After our discussion, I'd suggest starting completely fresh with a minimal test project, separate from your actual application. The goal here is to isolate your infrastructure from your app's code, so I know where things break without your business logic getting in the way.

Server Prerequisites

Before touching IIS or your project, verify your server is actually ready to host an ASP.NET Core app. Confirm which .NET version your app targets, then install the matching ASP.NET Core Hosting Bundle on the server - not just the runtime, not the SDK, but specifically the hosting bundle. Microsoft documents what it includes and how to install it at learn.microsoft.com/en-us/aspnet/core/host-and-deploy/iis/hosting-bundle.

After installing, run iisreset in an admin terminal, then open IIS Manager -> Modules and confirm AspNetCoreModuleV2 is listed.

If it's not there, the hosting bundle didn't register correctly, and nothing will work past this point.

Get the App Running Locally on IIS, No Domain Involved Yet

Create a brand new minimal ASP.NET Core Web API project with a single health check endpoint - something that just returns a simple response so you know the app is alive. Publish it and deploy it to IIS bound to HTTP on port 8080 with no hostname. Make sure the application pool is set to No Managed Code, which is required for ASP.NET Core as covered in learn.microsoft.com/en-us/aspnet/core/host-and-deploy/iis, and that the app pool identity has read/write access to the deployment folder.

Open a browser on the server itself and hit both the health endpoint and Swagger UI over http://localhost:8080.

If either of these fail, stop here. Do not proceed to the domain. Share the stdout log from your deployment folder and a screenshot of the error.

Add the Domain, Only After Step 1 Fully Passes

Add a new IIS binding for HTTP on port 80 with your hostname set to your-domain.com. Then, on the server, run a DNS lookup to confirm your-domain.com resolves to your server's public IP. If it doesn't resolve correctly, no IIS configuration will fix that - it needs to be corrected at your DNS provider first. Once DNS is confirmed, test the same health and Swagger endpoints over http://your-domain.com.

If Step 1 passed but this fails, the issue is either DNS or the IIS binding, not your app.

Add SSL, Only After Step 2 Fully Passes

Add an HTTPS binding on port 443 with your hostname and select your certificate. Test the same endpoints over https://your-domain.com.

If Step 2 passed but this fails, the certificate binding is where to look, not anything deeper.

---

Each step acts as a gate. I understand it feels like extra steps, but skipping ahead is what leads to the back-and-forth we've had so far.

Please give this a try and give me the result at each step. If you get stuck, share the exact error messages and logs from that step, and I can help you troubleshoot from there.

Thank you for your time.

Answer 4

Peter,

To get past the confusion of URLs and ports, I suggest performing a simple "Static File Test." This will tell us exactly what your URL path should be without the complexity of the Web API code.

Please follow these exact steps:

Create a Test File: On your desktop, create a new text file named index.html. Paste the following code into it and save it:

<html><body><h1>IIS Routing Test Successful</h1></body></html>

Clear the Server Folder: Go to the physical folder on your server where you have been deploying your DLLs. Move all existing files into a backup folder so the main folder is empty.

Deploy the Test File: Copy your new index.html into that empty server folder.

The "Browse" Test: * Open IIS Manager on the remote server.

Select your application in the left-hand tree.

On the far-right Actions panel, under "Browse Website," click the link that says "Browse *:443 (https)".

What to report back to the community:

A browser window should open. Even if the browser's address bar says localhost, we need to know the exact path that appears in the address bar.

Example: https://localhost/Web_app/index.html

Example: https://localhost/WebApp1/index.html

Or maybe a different path entirely.

Why we are doing this:

Community support relies on accurate data. For weeks, we have been guessing your URL alias (and port). This test will reveal the exact path IIS expects. Once we see the result of this "Browse" test, we will finally know the correct URL and can then help you fix the 500 error in your Web API.