WCF EndpointNotFoundException: There Was No Endpoint Listening at the Specified URL

The error "There was no endpoint listening at [URL] that could accept the message" is one of the most common WCF exceptions, and also one of the most misleading. It implies the URL is wrong, but the actual cause could be anything from a stopped application pool to a Windows firewall rule. This guide covers every realistic cause and gives you a systematic diagnostic workflow.

The Full Error Message

The exception typically looks like this:

System.ServiceModel.EndpointNotFoundException:
There was no endpoint listening at http://server:8080/MyService.svc
that could accept the message. This is often caused by an incorrect address
or SOAP action. See InnerException, if present, for more details.

Inner Exception:
System.Net.WebException: The remote server returned an error: (404) Not Found.

The inner exception is the real clue. While the outer EndpointNotFoundException is generic, the inner WebException tells you what HTTP status code was returned. Common inner exceptions include:

Cause 1: URL Mismatch

The most straightforward cause. The endpoint address in your client configuration does not match the actual address where the service is hosted.

Check the basics:

<!-- Client config -->
<endpoint address="http://server:8080/MyService.svc"
          binding="basicHttpBinding"
          contract="IMyService" />

Common URL mistakes:

• Wrong port number. The default IIS port is 80, but self-hosted services often use custom ports.
• Missing .svc extension. WCF services hosted in IIS require the .svc file extension in the URL.
• HTTP vs HTTPS mismatch. If the server is configured for HTTPS only, an HTTP request will fail.
• Trailing slash differences. Some WCF configurations are sensitive to trailing slashes.
• Case sensitivity. While IIS URLs are case-insensitive, Linux-hosted services (via .NET Core) may be case-sensitive.

Quick verification — try opening the service URL in a browser:

curl -v http://server:8080/MyService.svc

If you get a valid WSDL page or WCF metadata page, the URL is correct and the issue is elsewhere. If you get a 404, the URL or deployment is wrong.

Cause 2: Service Not Started or Not Deployed

For IIS-hosted services:

1. Check if the .svc file exists at the expected path under the IIS site's physical directory.

2. Verify the application is created in IIS Manager. Having files in a folder is not enough — IIS must have an Application (not just a Virtual Directory) pointing to that path.

3. Confirm the application pool is running:

# Check app pool status
Get-WebAppPoolState -Name "MyAppPool"

# Restart if stopped
Start-WebAppPool -Name "MyAppPool"

4. Check the Event Viewer (Windows Logs > Application) for errors that occurred when the app pool started. A common issue is the app pool crashing on startup due to a missing dependency or bad config, then IIS disabling it after repeated failures.

For self-hosted services (Windows Service or console app):

# Check if the service process is running
Get-Process -Name "MyServiceHost" -ErrorAction SilentlyContinue

# Check Windows Service status
Get-Service -Name "MyWcfService"

Cause 3: Firewall or Network Configuration

If the service URL works locally on the server but not from the client machine, the issue is network-level.

Windows Firewall:

# Check if the port is open
Test-NetConnection -ComputerName server -Port 8080

# Add a firewall rule if needed
New-NetFirewallRule -DisplayName "WCF Service Port 8080" `
    -Direction Inbound -Protocol TCP -LocalPort 8080 -Action Allow

Network-level checks:

# From the client machine
telnet server 8080

# Or using PowerShell
Test-NetConnection -ComputerName server -Port 8080 -InformationLevel Detailed

If Test-NetConnection shows TcpTestSucceeded: False, the issue is between the client and server — a firewall, load balancer, or network segmentation rule is blocking traffic.

Cause 4: HTTP.sys URL Reservation (Self-Hosted Services)

Self-hosted WCF services (not in IIS) need an HTTP.sys URL reservation to listen on a specific port. Without it, the service throws an AddressAccessDeniedException on startup and never begins listening.

Check existing reservations:

netsh http show urlacl

Add a reservation:

netsh http add urlacl url=http://+:8080/MyService/ user="NT AUTHORITY\NETWORK SERVICE"

If you're running the service under a specific account, replace the user parameter accordingly. After adding the reservation, restart the service.

Cause 5: Incorrect Binding or Endpoint Configuration on the Server

The server may be running, but the WCF endpoint configuration might not expose the expected address. Check the server's web.config or app.config:

<system.serviceModel>
  <services>
    <service name="MyNamespace.MyService">
      <!-- This is the address clients must use -->
      <endpoint address=""
                binding="basicHttpBinding"
                contract="MyNamespace.IMyService" />
      <!-- A relative address creates a sub-path -->
      <endpoint address="secure"
                binding="wsHttpBinding"
                contract="MyNamespace.IMyService" />
    </service>
  </services>
  <serviceHostingEnvironment aspNetCompatibilityEnabled="true"
                             multipleSiteBindingsEnabled="true" />
</system.serviceModel>

Pay attention to the address attribute on the endpoint element. An empty string means the endpoint is at the base address. A value like "secure" means the endpoint is at http://server:8080/MyService.svc/secure.

Cause 6: IIS Application Pool Identity and Permissions

Even if the app pool is running, it might not have permission to access resources the service needs during initialization:

# Check the app pool identity
Get-ItemProperty "IIS:\AppPools\MyAppPool" -Name processModel.identityType

# Common fix: grant read access to the service directory
icacls "C:\inetpub\MyService" /grant "IIS AppPool\MyAppPool:(OI)(CI)R"

If the app pool crashes silently due to permission errors, the service becomes unavailable without any obvious indication — the client simply sees EndpointNotFoundException.

Systematic Diagnostic Workflow

When you encounter this error, follow these steps in order:

Step 1: Verify the URL is reachable

# From the client machine
curl -v http://server:8080/MyService.svc

If you get a valid response, skip to Step 4. If not, continue.

Step 2: Test network connectivity

curl -v telnet://server:8080

If the connection is refused, check firewalls and verify the service process is listening.

Step 3: Verify the service is running on the server

# Check what's listening on the expected port
netstat -ano | findstr ":8080"

If nothing is listening, the service hasn't started. Check Event Viewer, service logs, and app pool status.

Step 4: Compare client and server endpoint configurations

Open both config files side by side and verify:

• Address matches exactly (including scheme, host, port, path)
• Binding type matches (both sides must use the same binding)
• Contract namespace and name match

Step 5: Enable WCF tracing on the server

<system.diagnostics>
  <sources>
    <source name="System.ServiceModel" switchValue="Information, ActivityTracing">
      <listeners>
        <add name="traceListener"
             type="System.Diagnostics.XmlWriterTraceListener"
             initializeData="c:\logs\wcf-trace.svclog" />
      </listeners>
    </source>
  </sources>
</system.diagnostics>

Open the resulting .svclog file in the Service Trace Viewer (SvcTraceViewer.exe) to see whether the server received the request at all.

When the Inner Exception Is Not (404)

If the inner exception shows (503) Service Unavailable, the server process exists but is temporarily unable to handle requests. Common triggers:

• App pool is recycling. By default, IIS recycles app pools every 1740 minutes (29 hours). During recycling, requests briefly fail.
• App pool has been disabled after rapid failures. Check %systemdrive%\inetpub\logs\LogFiles for patterns.
• Connection limit reached. WCF has a default throttle of 16 concurrent sessions, 16 concurrent calls, and 16 concurrent instances. Under load, this can cause 503 errors.

Increase service throttling if needed:

<serviceBehaviors>
  <behavior name="ThrottledBehavior">
    <serviceThrottling maxConcurrentCalls="64"
                       maxConcurrentSessions="200"
                       maxConcurrentInstances="200" />
  </behavior>
</serviceBehaviors>

How SOAPless Helps

Tracking down EndpointNotFoundException requires access to the server's configuration, IIS Manager, firewall rules, and HTTP.sys settings. When you're consuming a third-party SOAP service, you often don't have access to any of these — you can only guess whether the URL is correct and hope the service is running.

SOAPless removes this guesswork. Paste the WSDL URL into the SOAPless dashboard, and it validates the endpoint, generates REST JSON endpoints, and provides a built-in test panel so you can verify connectivity immediately. If the upstream service changes its URL or goes down, you see clear diagnostics in your dashboard instead of opaque .NET exceptions.

Authentication credentials are encrypted with AES-256-GCM, and you get an auto-generated OpenAPI spec for your REST endpoints. No WCF config files, no binding mismatches, no endpoint debugging — just a clean JSON API that works.