Inbound Web Services — No Response and Connection Failures - Support and Troubleshooting

Inbound Web Services — No Response and Connection Failures .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Contents Issue — What This Article Covers Quick Triage The Connection Path — Where Failures Occur Five Causes — Diagnosis and Fix 4.1 Firewall, Proxy, or IP Allowlist 4.2 TLS / Certificate Trust Chain 4.3 Connection Refused or Connection Reset 4.4 HTTP 499 — Client Closed the Connection 4.5 CORS — Missing Access-Control-Allow-Origin Header What to Capture Before Opening a Case Related Articles 1. Issue — What This Article Covers Inbound web service calls that never reach the instance, or fail during the connection and handshake phase before any authentication or processing takes place.

Symptoms covered:

No response from the instance — the call hangs or times out without any HTTP status code. Connection refused or connection reset by the remote side. TLS handshake failure or certificate error. HTTP 499 — the client closed the connection before the instance finished responding. CORS error in the browser console: No 'Access-Control-Allow-Origin' header is present on the requested resource . Debug logging is enabled but the failing request never appears in the instance logs — the call is not reaching the instance at all. How to use this article: Start with the Quick Triage in Section 2. If the request is reaching the instance but failing with a 401 or 403, this is not the right article — see Inbound Web Services — Authentication and Authorization Failures .

↑ Back to top

2. Quick Triage Match your symptom to find the right subsection.

What you are seeing Most likely cause Go to Call hangs or times out, no HTTP status code returned, no entry in instance logs Firewall, proxy, or IP allowlist blocking the request before it reaches the instance Section 4.1 TLS handshake error, certificate untrusted, or SSL negotiation failure Certificate not trusted, hostname mismatch, or TLS version / cipher mismatch Section 4.2 Connection refused or connection reset Wrong port, protocol mismatch, or remote side actively rejecting the connection Section 4.3 HTTP 499 Client closed the connection before the instance finished; client-side timeout is shorter than server processing time Section 4.4 CORS error in browser console only; server-side call to the same endpoint works fine Missing or misconfigured CORS rule on the instance Section 4.5 Universal fast check: enable debug logging and make a failing call. If no entry appears in the instance Transaction Log or System Log, the request is not reaching the instance — the problem is in the network path, not in the platform. Go to Section 4.1 .

Available debug properties:

REST: glide.rest.debug SOAP: glide.processor.debug.SOAPProcessor JSONv2: no dedicated debug property — use the Transaction log. ↑ Back to top

3. The Connection Path — Where Failures Occur Before a request can be authenticated or processed, it must travel through three layers: the client-side network, the public internet and any intermediate proxies, and the ServiceNow load balancer and application nodes. A failure at any of these layers produces a different symptom and requires a different fix.

↑ Back to top

4. Five Causes — Diagnosis and Fix 4.1 Firewall, Proxy, or IP Allowlist Signature: the call never arrives at the instance. Debug logging shows no entry for the failing request. The client receives no HTTP response, or a generic network timeout.

Why this happens: a customer-side firewall, proxy, or egress filter is blocking outbound traffic to the ServiceNow instance IP ranges. This is the most common cause of complete silence from the instance.

Confirm it:

Enable glide.rest.debug and make a failing call. If nothing appears in Transaction Logs, the call is not reaching the node. From the client machine, attempt a plain TCP connection to the instance hostname on port 443. If it fails immediately, the firewall is blocking the connection. Try the same call from a machine outside the customer network (e.g., a cloud shell or personal connection). If it succeeds, the block is on the customer side. Fix:

Retrieve the current IP ranges for your instance using the Now Support Automation Store. See KB0538621 — How to find IP address and datacenter information for your instance . Add the returned IP ranges to the outbound allowlist on the customer firewall or proxy. If the instance was recently migrated to a new datacenter, the IP ranges will have changed — re-run the lookup even if the allowlist was previously correct. For instances on ADCv2, note the known issue where the "address to which your instance resolves" field may appear empty in the lookup result. This is a display issue — use the IP ranges returned in the other fields. ↑ Back to top

4.2 TLS / Certificate Trust Chain Signature: the TCP connection is established but immediately closed. The client reports a TLS handshake failure, an untrusted certificate, a hostname mismatch, or an SSL negotiation error. Common error strings:

javax.net.ssl.SSLHandshakeException PKIX path building failed No subject alternative DNS name matching found unknown_ca or certificate_unknown Common causes:

The client's trust store does not include the certificate authority (CA) that signed the ServiceNow instance certificate. The hostname in the request does not match any Subject Alternative Name (SAN) on the server certificate — common when using a custom vanity URL or a recently renamed instance. The client enforces a minimum TLS version (e.g., TLS 1.3) that differs from what the server is negotiating. An intermediate proxy or corporate SSL inspection appliance is intercepting the connection and presenting its own certificate, which the client does not trust. Fix:

Confirm the client trust store includes the issuing CA for the ServiceNow certificate. You can inspect the certificate chain by opening the instance URL in a browser and viewing the certificate details. Verify the hostname in the request exactly matches a SAN entry on the server certificate. If a corporate SSL inspection appliance is in the path, either add its certificate to the client trust store or configure the appliance to bypass inspection for the ServiceNow instance domain. Check whether the client and server can agree on a TLS version. ServiceNow supports TLS 1.2 and TLS 1.3. ↑ Back to top

4.3 Connection Refused or Connection Reset Signature: the connection attempt is actively rejected by the remote side ( Connection refused ) or the connection is established and then immediately closed ( Connection reset ). No HTTP response is received.

Common causes:

The request is targeting the wrong port. ServiceNow instances accept inbound HTTPS on port 443. Port 80 (HTTP) is not accepted. A protocol mismatch: attempting plain HTTP against an HTTPS endpoint, or vice versa. A firewall or load balancer is actively resetting connections from disallowed source IPs rather than dropping them silently. The instance is in an outage or maintenance state and the load balancer is actively refusing connections. Fix:

Confirm the request URL uses https:// and targets port 443. Confirm the instance is reachable by opening the instance URL in a browser. If the browser also fails, check the ServiceNow Status Page for active incidents. If the connection is reset rather than refused, check whether the source IP is on an allowlist. Some instances are configured to only accept connections from specific IP ranges. ↑ Back to top

4.4 HTTP 499 — Client Closed the Connection Signature: the load balancer log records a 499 status code. The client receives no response or a timeout error. On the instance side, the node may have continued processing the request and completed successfully — but the client had already given up.

Why this happens: HTTP 499 is issued by the ServiceNow ADC (load balancer) when the client closes the TCP connection before the node finishes processing and sends a response. This is not a server error. The instance may have processed the request correctly — the client just did not wait long enough to receive the answer.

Two scenarios:

Client timeout too short: the client has a connection or read timeout that is shorter than the time the instance needs to process the request. The client gives up and closes the connection. The instance finishes and responds to nobody. Slow request on the instance side: the request is taking longer than expected due to a slow query, missing index, or heavy workload. The client's timeout is reasonable, but the instance is not meeting it. In this case the 499 is a symptom of a deeper performance problem. Fix:

Check whether the instance actually processed the request by looking in the target table or System Log for an entry at the timestamp of the failure. If the record exists, the instance completed the operation — the only problem is the client did not receive the confirmation. If the client timeout is simply too short, increase it to allow more time for the instance to respond. For REST calls, a 30–60 second read timeout is a reasonable starting point for most integrations. If the instance is genuinely slow (the request takes longer than expected regardless of the client timeout), investigate the underlying cause using Inbound Web Services — Timeouts and Slow Responses . If 499s are occurring in bursts, check whether a client retry loop is compounding the problem: each retry re-queues work on the instance while previous requests are still running. ↑ Back to top

4.5 CORS — Missing Access-Control-Allow-Origin Header Signature: a browser-based client calling a ServiceNow API from a different origin is blocked. The error appears in the browser console, not in the server logs:

No 'Access-Control-Allow-Origin' header is present on the requested resource Cross-Origin Request Blocked The same call made from a non-browser client (Postman, curl, a server-side script) succeeds without error. This is because CORS is enforced by browsers only — it is not a server-side access control.

Why this happens: when a browser makes a cross-origin request (the calling page is on a different domain than the ServiceNow instance), the browser first sends a preflight OPTIONS request. The instance must respond with CORS headers that explicitly permit the calling origin. If no matching CORS rule exists on the instance, the browser blocks the response.

Fix:

Navigate to System Web Services → REST → CORS Rules ( sys_cors_rule ). Create a new rule (or correct an existing one) with: REST API: the specific Scripted REST API or Table API being called. Domain: the exact origin of the calling page (e.g., https://myapp.example.com ). Wildcards ( * ) are supported but should be avoided in production. HTTP Methods: all methods the client will use (GET, POST, PUT, PATCH, DELETE as appropriate). HTTP Headers: any custom request headers the client sends (e.g., Content-Type , Authorization ). Confirm the preflight OPTIONS request succeeds before the actual request. You can inspect the OPTIONS exchange in the browser's Network tab. Note: CORS rules apply per REST API definition. If the same origin needs to call multiple APIs, a rule is required for each one. ↑ Back to top

5. What to Capture Before Opening a Case If self-diagnosis does not resolve the issue, gather the following before opening a support case. These items resolve most cases at first touch.

The exact request — full URL, HTTP method, and any relevant headers (sanitize credentials before sharing). Time of failure to the second, with timezone (UTC preferred). Client IP address and the network path taken (direct internet, VPN, corporate proxy). Exact error message from the client, including any exception class or error code. Debug log result — confirm whether or not the failing request appears in the instance Transaction Log. Instance IP ranges currently in use, from KB0538621 . Recent change context — firewall rule changes, proxy configuration changes, certificate renewals, or instance datacenter migrations in the last 30 days. ↑ Back to top

6. Related Articles Inbound Web Services — Troubleshooting Guide (hub) Inbound Web Services — Authentication and Authorization Failures Inbound Web Services — Timeouts and Slow Responses KB0538621 — How to find IP address and datacenter information for your instance ↑ Back to top