tcping Works but HTTPS Fails? Troubleshoot Layer by Layer Across DNS, TLS, HTTP, and CDN Origin Fetching

A tcping test of port 443 on the server may look normal, while the browser says “Unable to establish a secure connection.” Or the port probe may succeed, yet the site ends up returning 403, 502, or even timing out. These symptoms are not contradictory.

tcping usually only verifies whether a TCP connection can be established. HTTPS must then complete the TLS handshake, certificate validation, and the HTTP request and response. If the domain is served through a CDN, there may also be a separate origin-facing connection between the CDN edge node and the origin. The TLS handshake comes after the TCP connection; for details, seeTLS handshake process.

The focus, therefore, is not to keep testing port 443 repeatedly, but to identify the last layer the request reached successfully:

DNS解析
→ TCP连接
→ TLS握手
→ 证书验证
→ HTTP请求
→ CDN边缘规则
→ CDN回源
→ 源站程序

What does a successful tcping test actually prove?

A successful tcping result usually only means the test host can open a TCP connection to port 443 on a target IP and receive a response. It can help determine:

• whether port 443 on the target IP is listening;

• whether the current network is blocking TCP connections entirely;

• whether a firewall is dropping connection requests outright;

• the approximate time taken to establish the TCP connection.

However, tcping cannot prove the following:

• that DNS resolves to the IP you tested;

• that the server returned the certificate for the correct domain;

• that the TLS version and cipher suite can be negotiated;

• that the certificate has not expired, matches the domain, and has a complete chain;

• that the WAF allows the current client to access the site;

• that the CDN can reach the origin normally;

• that the web application can return the correct page;

• that the scripts, APIs, and images loaded by the browser are all accessible.

Think of it as the main door downstairs opening: it does not yet prove you can pass access control, enter the right room, and get the service you need.

Use curl to identify the failing step first

Do not start by changing certificates, clearing caches, or opening firewall rules. First record the full process of one real HTTPS request.

curl --noproxy '*' -sS -v \
  --connect-timeout 5 \
  --max-time 20 \
  -o /dev/null \
  -w "\ncode=%{http_code}\nremote_ip=%{remote_ip}\nname=%{time_namelookup}\nconnect=%{time_connect}\ntls=%{time_appconnect}\nttfb=%{time_starttransfer}\ntotal=%{time_total}\n" \
  https://www.example.com/

On Windows, you can usecurl.exe. If you do not want to bypass the system proxy, first remove--noproxy '*', then record the two results separately.

Focus on these fields:

• remote_ip: the IP actually connected to. It may differ from the IP used in the tcping test.

• code: the final HTTP status code.

• time_connect: cumulative time when the TCP connection completed.

• time_appconnect: cumulative time when the TLS or other security protocol handshake completed.

• time_starttransfer: cumulative time until the first byte of the response was received.

• time_total: cumulative time for the entire request.

These times are cumulative values measured from the start of the request. Do not directly treattime_appconnectas pure TLS time. For exact field definitions, seecurl official timing variables documentation.

The results can initially be grouped as follows:

http_code=000This does not mean the server returned a status code called “000”; it means curl did not receive a valid HTTP response. Go back to the verbose log and determine whether the failure occurred during connection, TLS, or reading the response.

Check DNS first: is the IP used in the tcping test the same IP that HTTPS actually uses?

Many investigations go off track at the first step: tcping manually tests one IP, while the browser resolves the domain to a different address.

First check the domain’s CNAME, IPv4, and IPv6 records:

dig +short CNAME www.example.com
dig +short A www.example.com
dig +short AAAA www.example.com

If you do not havedig, you can also use:

nslookup -type=A www.example.com
nslookup -type=AAAA www.example.com

Key points to confirm:

1. whether the domain has both A and AAAA records;

2. whether the IP used for tcping is still in the DNS response list;

3. whether different DNS servers return different results;

4. whether only a specific CDN node or address is failing;

5. whether HTTPS access goes through a proxy while tcping does not.

Then test IPv4 and IPv6 separately:

curl --noproxy '*' -4 -v --connect-timeout 5 --max-time 20 -o /dev/null https://www.example.com/
curl --noproxy '*' -6 -v --connect-timeout 5 --max-time 20 -o /dev/null https://www.example.com/

If IPv4 succeeds and IPv6 fails, focus on AAAA records, IPv6 routing, IPv6 listening, IPv6 firewalls, and the CDN’s IPv6 entry point. Do not conclude that the site’s IPv6 configuration is wrong just because one computer has no IPv6 network.

Conversely, if tcping tests IPv4 but the browser prefers IPv6, then “tcping works but the browser fails” is actually comparing two different network paths.

After TCP connectivity, what else must the TLS handshake verify?

SNI is the part of HTTPS most often overlooked. One IP address can host multiple HTTPS domains, so the client must tell the server which domain it wants during the TLS handshake; the server can then select the corresponding certificate.

You can test with OpenSSL:

openssl s_client \
  -connect www.example.com:443 \
  -servername www.example.com \
  -verify_hostname www.example.com \
  -verify_return_error \
  </dev/null

Focus on the following:

• whether the certificate subject and SAN returned by the server includewww.example.com;

• Verify return codewhether it is 0;

• whether the certificate validity period is normal;

• whether the server sent the necessary intermediate certificates;

• the TLS version and cipher suite actually negotiated;

• whether any of the following appear:handshake failure,certificate verify failedorunrecognized name.

For the specific behavior of each parameter, seeOpenSSL s_client certificate debugging optionsfor reference.

Common issues include:

Certificate domain mismatch

For example, the site is accessed atwww.example.combut the certificate returned by the edge node only includesapi.example.com. TCP can of course connect, but the browser will block it during certificate validation.

Incomplete certificate chain

Some clients may work temporarily because they have cached an intermediate certificate locally, while another device reports that the certificate is untrusted. The server should send the complete required certificate chain and must not rely on a user device happening to have cached the certificate.

SNI misconfiguration

If multiple domains share one IP and the CDN, load balancer, or origin does not correctly identify SNI, the server may return the default site certificate or reject the handshake outright.

TLS version or cipher suite incompatibility

When you actually need to isolate a protocol difference, test separately:

curl --noproxy '*' -v \
  --tlsv1.2 --tls-max 1.2 \
  --connect-timeout 5 --max-time 20 \
  -o /dev/null https://www.example.com/

curl --noproxy '*' -v \
  --tlsv1.3 --tls-max 1.3 \
  --connect-timeout 5 --max-time 20 \
  -o /dev/null https://www.example.com/

These tests are for diagnosing compatibility issues; they do not mean the server should be permanently changed to an older TLS version. Do not treatcurl -kas a production fix. It only skips certificate validation and is at most useful for confirming whether an HTTP request can still be sent after bypassing validation.

If an HTTP status code has already been returned, stop calling it “443 unreachable”

As long as curl completes TLS and receives an HTTP status code, this request has at least passed the main stages of DNS, TCP, and TLS. The next question is why the request was rejected or why it did not return the correct content.

Use a GET request to read response headers rather than relying only on HEAD:

curl --noproxy '*' -sS \
  -D - \
  -o /dev/null \
  --connect-timeout 5 \
  --max-time 20 \
  https://www.example.com/

Some web servers handle HEAD and GET differently, so a normal HEAD response does not fully represent a normal browser GET request.

Common statuses can be interpreted as follows:

• 200: the HTTP request for the current URL succeeded, but this does not mean all APIs and static resources the page depends on are working.

• 301or302: checkLocationwhich domain, port, and protocol it redirects to.

• 403: usually check the WAF, access control, hotlink protection, geographic rules, or request characteristics.

• 429: focus on rate limits, client IP reputation, and whether requests are concentrated through the same egress.

• 500: more likely an origin application or upstream program error.

• 502or504: check the gateway, load balancer, CDN origin fetch, and origin response.

• 525,526and other vendor-specific codes: always refer to the specific CDN vendor’s error definitions. Do not apply one CDN’s code interpretations to every platform.

You can useHTTP status code classesto understand the standard status code classes, but the status code alone usually cannot tell you whether the error came from the CDN or the origin.

Also check the redirect chain:

curl --noproxy '*' -sS \
  -D - \
  -o /dev/null \
  --connect-timeout 5 \
  --max-time 20 \
  https://www.example.com/

If the response containsLocation, continue testing the target address. The entry domain may be working, but the login domain, static resource domain, or API domain it redirects to may still have TLS issues.

After CDN integration, check origin HTTPS separately

The connection from the visitor to the CDN edge node is one segment; the connection from the CDN to the origin is another. A front-end tcping test only proves that the visitor can establish a TCP connection to the edge node; it does not prove that the CDN can fetch from the origin successfully.

If you are authorized and know the origin test IP, you can usecurl --resolve:

curl --noproxy '*' \
  --resolve www.example.com:443:203.0.113.10 \
  -sS -v \
  --connect-timeout 5 \
  --max-time 20 \
  -o /dev/null \
  -w "\ncode=%{http_code}\nremote_ip=%{remote_ip}\ntotal=%{time_total}\n" \
  https://www.example.com/

The key here is not direct access:

https://203.0.113.10/

instead, continue using:

https://www.example.com/

--resolvepoint the domain temporarily to the specified IP only, so the correct HTTP Host and TLS SNI are preserved. This approach is better suited to testing multi-site origins than accessing the origin IP directly over HTTPS.

Check origin testing against the actual configuration:

• whether the CDN origin protocol is HTTP or HTTPS;

• whether the origin port is correct;

• which domain the origin SNI uses;

• whether the origin Host is rewritten;

• whether the origin certificate matches the origin domain;

• whether the origin firewall allows CDN origin IPs;

• whether load balancer health checks use the correct protocol and path;

• whether the origin requires specific request headers, client certificates, or authentication information.

If the origin allows only CDN origin fetches, a failed direct external connection may be a normal security policy. In that case, use the CDN vendor’s origin logs, health checks, and edge diagnostics. Do not temporarily disable the firewall or permanently open the origin just for troubleshooting.

The logic can be summarized simply:

This is not an absolute conclusion, but it is more effective than simply clearing the cache after seeing a 502.

CdnChart troubleshooting approach: first examine failure distribution, then average latency

When troubleshooting CDN issues, the tcping result from a single node provides limited information. More valuable questions are:

• Is the failure in all regions, or only one region?

• Do all three carriers fail, or is only China Mobile or China Unicom affected?

• Do failed nodes receive the same response IP, or only some of multiple IPs?

• Does the failure occur at the connection stage, or has an HTTP status code such as 403 or 502 already been returned?

• Does the homepage fail for the same domain, or does only one API path fail?

CdnChart recommends first assessing the failure distribution, then investigating specific configuration. You can useCdnChart website speed testto observe the region, carrier, response IP, HTTP status code, connection time, total time, and failed nodes across test nodes, rather than focusing only on a single average speed.

You can narrow the scope as follows:

If the response IP, CNAME, and certificate information are inconsistent, you can also useCDN detection toolto check evidence such as public CNAME records, response IPs, ASNs, response headers, and TLS certificates. The focus here is the combination of evidence: do not identify a CDN vendor from a single response header, and do not conclude that a domain does not use a CDN just because no detection result appears.

This is also where CdnChart differs from a single port probe: a port probe answers “can a given port on an address be connected to,” while multi-node speed tests and CDN detection help answer “is the problem concentrated in a specific region, carrier, response IP, or service path.”

Change only one variable at a time so test results remain comparable

The most common mistake in troubleshooting is changing DNS, certificates, WAF, and origin configuration all at once, then finding the site recovered without knowing the real cause.

A more reliable approach is to keep the following fixed:

• the full URL and request path;

• query parameters;

• Host and SNI;

• the test client;

• the test time;

• whether a proxy is used;

• the IPv4 or IPv6 address family;

• whether redirects are followed.

Then change only one variable at a time. For example:

1. first test the normal domain and record the actual response IP and status code;

2. then usecurl -4andcurl -6to compare address families;

3. then use OpenSSL to check the certificate and SNI for the same domain;

4. then use--resolveto pin to the authorized origin IP;

5. finally, use multi-region nodes to confirm whether the problem is still concentrated in a specific network.

CdnChart testing methodologyis better suited to understanding a consistent testing methodology, sample comparison, and metric boundaries. It cannot replace origin logs, CDN origin logs, or internal enterprise monitoring, but it can help determine which set of nodes, which address, or which time window to focus logs on.

After the fix, repeat the original test matrix. At minimum, confirm:

• the previously failing IPv4 or IPv6 path has recovered;

• TLS certificate, SNI, and certificate chain validation are normal;

• the expected URL returns the correct 2xx or 3xx;

• failed nodes are no longer concentrated;

• there are no new handshake or timeout errors in the CDN origin logs;

• APIs, scripts, and key business requests on the page also complete.

A single 200 from the homepage only proves that one homepage request succeeded; it is not a substitute for full acceptance testing.

Common questions

tcping works, but curl reports a TLS handshake failure. Where is the problem?

Check the certificate, SNI, TLS version, cipher suite, client time, and proxy first. tcping completes only the TCP-layer connection; a TLS failure means the request has not yet reached normal HTTP processing.

Addingcurl -kmakes the site accessible—does that mean it has been restored?

No.-kIt skips certificate validation. It can help determine whether the problem is certificate-related, but a production fix should still address the certificate domain, validity period, certificate chain, or client trust issue.

curl returns 200. Why can’t the browser open the site?

The browser may also request APIs, scripts, images, fonts, and third-party resources. There may also be proxy, browser extension, cache, HSTS, mixed content, or cookie policy issues. Identify the requests that actually fail in the browser network panel instead of looking only at the curl result for the homepage.

Can I test HTTPS by accessing the origin IP directly?

It is not recommended to usehttps://203.0.113.10/to test origin HTTPS. This can cause incorrect Host and SNI. After obtaining authorization, usecurl --resolveto direct the connection to a specified IP while preserving the real domain.

IPv4 works but IPv6 fails. Can I simply delete the AAAA record?

Do not do that directly. First confirm IPv6 listening, routing, firewalls, CDN nodes, and certificate configuration. Deleting the AAAA record may temporarily bypass the problem, but it will remove IPv6 access for users who have IPv6 connectivity.

The CDN edge node returns 200. Why are there no access logs on the origin?

If the request hits the cache, the CDN may return edge content directly, and the origin would not receive the request at all. Only cache misses, dynamic requests, or requests that require origin fetch should appear in origin records.

Can a successful tcping result rule out HTTP/3 issues?

No. HTTP/3 is based on QUIC and uses UDP; a TCP port test does not cover this path. Check the protocol actually negotiated by the browser, or verify separately with an HTTP/3-capable client. For the HTTP/3 protocol definition, seeHTTP/3 specification.