High TLS Handshake Time? Check These 8 Issues Before Switching CDNs

In website speed test results, DNS takes only a dozen milliseconds, TCP connection is not slow either, yet the TLS handshake takes several hundred milliseconds, sometimes even over a second. Seeing this, many people's first reaction is: the CDN node is bad, time to switch providers.

This judgment is sometimes correct. For example, if target users are too far from the CDN node, carrier routing takes a detour, or the node is not deployed in the user's region, TLS handshake time will rise. But TLS latency is not determined only by the CDN brand. Differences between IPv4 and IPv6 paths, packet loss, certificate chain, TLS version, enterprise proxy, client performance, and even the timing methodology of the speed test tool can all make 'high TLS handshake' look like a CDN fault.

Before switching CDNs, you should answer at least three questions:

1. Is the measured value really pure TLS handshake time?

2. Does the problem occur in all regions, or is it concentrated in a certain region, carrier, or IP protocol?

3. Is the slow part the edge handshake from the user to the CDN, or the origin handshake from the CDN to the origin server?

If these three points are not distinguished, you may still encounter the same problem after switching CDNs.

First confirm what 'TLS time' means in the speed test tool

A new HTTPS connection roughly consists of:

DNS解析
   ↓
建立TCP连接
   ↓
TLS握手
   ↓
发送HTTP请求
   ↓
等待首字节
   ↓
下载响应内容

Some speed test tools show each stage separately, while others may display 'SSL time' or 'connection time' as a cumulative value. For example, if a tool showsTLS完成时间为300ms, it does not necessarily mean the TLS stage alone took 300ms. It may mean that from request start to TLS handshake completion took 300ms total, already including DNS and TCP connection time.

Chrome DevTools also distinguishes DNS Lookup, Initial connection, and SSL, but connection reuse, proxy negotiation, and retries can affect how the waterfall is displayed. Chrome's officialNetwork panel documentationpoints out that Initial connection may include TCP connection, retries, and SSL negotiation. You cannot attribute an entire long connection block to TLS just because it appears.

Also note connection reuse. The second or third HTTPS resource on a page may continue using an already established HTTP/2 or HTTP/3 connection, so a full TLS handshake will not appear again. Conversely, if a speed test tool forces a new connection every time, the results will be worse than what ordinary users experience during continuous browsing.

Therefore, to decide whether a CDN should be replaced, you cannot rely on a single screenshot of a browser waterfall. You need repeated measurements using clearly defined timing fields.

Use curl to break down DNS, TCP, TLS, and TTFB

You can use the following command to test a publicly accessible path:

curl -sS -o /dev/null \
  -w 'remote_ip=%{remote_ip}\nhttp_version=%{http_version}\ndns=%{time_namelookup}\nconnect=%{time_connect}\nappconnect=%{time_appconnect}\nstarttransfer=%{time_starttransfer}\ntotal=%{time_total}\n' \
  https://www.example.com/

The output may look like:

remote_ip=203.0.113.10
http_version=2
dns=0.018421
connect=0.072815
appconnect=0.151936
starttransfer=0.238104
total=0.241592

These values are all measured cumulatively from the start of the request. They can be approximately broken down as:

DNS阶段 ≈ time_namelookup
TCP阶段 ≈ time_connect - time_namelookup
TLS阶段 ≈ time_appconnect - time_connect
握手后等待首字节 ≈ time_starttransfer - time_appconnect

Using the example above:

DNS ≈ 18ms
TCP ≈ 54ms
TLS ≈ 79ms
握手后等待首字节 ≈ 86ms

curl officially definestime_connectandtime_appconnectas 'from start until connection establishment completes' and 'from start until application-layer handshake such as SSL completes'. So you cannot directly treattime_appconnectas pure TLS time; you usually need to subtracttime_connect.

This is still an engineering approximation. When an HTTPS proxy is used, redirects occur, or HTTP/3 is used, stage boundaries may differ. If the command includes-Lto follow multiple redirects, the timing values may also accumulate across multiple requests. During troubleshooting, it is advisable to first test the final HTTPS URL without following redirects.

Look at TCP first, then TLS: when network distance is high, the handshake is unlikely to be low

A TLS handshake requires exchanging multiple messages between client and server. Even if the CDN node processes quickly, packets still have to travel back and forth over the network.

If the test result is:

TCP连接阶段：180ms
TLS阶段：190ms

The more likely situation is that there is already high round-trip latency between the user and the node. It is not surprising for TLS time to be close to one or more network round trips. The focus should be on node location, carrier interconnection, and network path.

If the result is:

TCP连接阶段：20ms
TLS阶段：700ms

TCP is fast but TLS is clearly abnormal, continue checking:

• Whether packet loss and retransmission occur during the TLS handshake;

• Whether the CDN edge node is overloaded;

• Whether enterprise proxies, security software, or TLS inspection devices are present;

• Whether the certificate chain is too large or misconfigured;

• Whether IPv4 and IPv6 connect to different nodes;

• Whether the client is performing additional certificate validation;

• Whether negotiation of a certain TLS version or cipher suite is abnormal.

You cannot set a fixed standard that applies to all regions worldwide, such as 'TLS over 200 ms is definitely unacceptable.' Reasonable baselines for users connecting to a same-city node, an international route, or a satellite network are completely different. A more meaningful approach is to compare P50 and P95 results under the same region, same carrier, and same protocol conditions.

CDNChart'sCDN speed test methodologyalso breaks down DNS, TCP, TLS, TTFB, and download stages to avoid mistaking the total time of a single request for a problem in one individual stage.

Check whether the issue is global or only occurs in certain regions

If you measure slow TLS handshake only once on your own computer, the evidence is not enough to justify switching CDNs.

It is recommended to repeat tests at least across the following dimensions:

地区：大陆、港澳台、亚洲其他地区、欧美等目标市场
运营商：电信、联通、移动及当地主要网络
协议：IPv4、IPv6
时间：业务高峰、非高峰
样本：连续多次，而不是只取一次
指标：中位数、P95、失败率

You can use CDNChart'swebsite speed test toolto observe stage timings and status differences for publicly accessible paths in different regions. Tool results are suitable for discovering 'which regions are abnormal,' but the cause should ultimately be determined together with the origin server, CDN console, and local commands.

Common distributions and likely directions are as follows:

If the anomaly is concentrated in a target market and a candidate CDN has more suitable nodes and carrier interconnection in that market, switching CDNs may produce clear benefits.

Test IPv4 and IPv6 separately

When a domain has both A and AAAA records, users may access different edge addresses over IPv4 or IPv6. The nodes, routes, and carrier interconnections for the two paths may differ.

Run separately:

curl -4 -sS -o /dev/null \
  -w 'ip=%{remote_ip} connect=%{time_connect} tls_done=%{time_appconnect} total=%{time_total}\n' \
  https://www.example.com/

curl -6 -sS -o /dev/null \
  -w 'ip=%{remote_ip} connect=%{time_connect} tls_done=%{time_appconnect} total=%{time_total}\n' \
  https://www.example.com/

If IPv4 is stable but the TLS stage over IPv6 is clearly higher, do not immediately judge the entire CDN as poor-performing. Continue checking:

• Whether the AAAA record points to the correct CDN;

• Whether IPv6 is reaching a farther node;

• Whether the IPv6 path has packet loss or detours;

• Whether the CDN provides equivalent-quality IPv6 service in the target region;

• Whether the origin server or security policies handle IPv6 differently.

Browsers may use connection racing to choose the faster protocol family. Command-line forced test results are not necessarily the same as the browser's final choice, but they can help identify differences.

If the DNS stage itself is high, address the resolution path first rather than using a CDN switch to mask the problem. For details, seeDoes slow DNS resolution slow down a CDN? How to troubleshoot domain name resolution time.

Check whether TLS 1.2 and TLS 1.3 perform differently

TLS 1.3 simplifies the handshake process. On a normal new connection, it can usually complete secure negotiation with fewer network round trips, making it more valuable on high-latency networks.

You can test separately:

curl --tlsv1.2 --tls-max 1.2 \
  -sS -o /dev/null \
  -w 'version=TLS1.2 connect=%{time_connect} tls_done=%{time_appconnect} total=%{time_total}\n' \
  https://www.example.com/

curl --tlsv1.3 --tls-max 1.3 \
  -sS -o /dev/null \
  -w 'version=TLS1.3 connect=%{time_connect} tls_done=%{time_appconnect} total=%{time_total}\n' \
  https://www.example.com/

Whether these parameters are supported depends on the local curl and its TLS library. Some older versions or specific builds may not support TLS 1.3.

The results can be interpreted as follows:

• TLS 1.3 consistently faster: check whether the CDN has enabled TLS 1.3 for target users;

• Both versions slow: more likely a network distance, packet loss, proxy, or node issue;

• TLS 1.2 normal, TLS 1.3 abnormal: check CDN edge configuration, middlebox compatibility, and client TLS library;

• Only certain clients abnormal: do not expand this into a site-wide CDN performance failure.

RFC 8446defines TLS 1.3 and adds 0-RTT mode, allowing some application data on resumed connections to save a round trip, but at the cost of certain security properties.

Do not blindly enable 0-RTT for logins, payments, orders, and other requests with side effects just to chase lower numbers. Early data has replay risks, and the allowed methods and security boundaries must be designed jointly by the CDN and the application.

Check the certificate chain, not just whether the certificate has expired

An unexpired certificate does not mean the TLS configuration is fully correct. Also check:

• Whether SNI returns the correct certificate;

• Whether the certificate SAN includes the accessed domain;

• Whether intermediate certificates are complete;

• Whether unnecessary duplicate certificates are sent;

• Whether the certificate chain is abnormally large;

• Whether different edge nodes return the same chain;

• Whether OCSP Stapling is provided;

• Whether the signature algorithm and key type are compatible with target clients.

You can run:

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

OpenSSL'ss_clientdocumentationlists-servername,-verify_hostname,-showcertsand-statusand other inspection parameters.

Focus on:

Protocol
Cipher
Certificate chain
subject
issuer
Verify return code
OCSP Response Status

Several judgment boundaries should be noted:

• A missing intermediate certificate more commonly results in certificate validation failure or incompatibility with some clients; it does not necessarily appear as high latency on all clients;

• An oversized certificate chain may increase handshake cost on high-latency, low-bandwidth, or lossy networks, but it is usually not the only cause;

• Lack of OCSP Stapling does not mean TLS must be slow; different browsers and systems handle online status checks differently;

• When a certificate has many SANs and a long chain, it can be an optimization target, but do not assume it is the main cause without comparative testing.

Check for packet loss and retransmission

The amount of data exchanged in a TLS handshake is not large, but it is sensitive to packet loss. If a key handshake packet is lost, it must wait for retransmission. The final symptom may be acceptable TCP connection time but sudden increases of hundreds of milliseconds or more in the TLS stage.

You can first run:

mtr -rwzc 50 www.example.com

Or:

traceroute www.example.com

Focus on observing:

• Whether the path clearly detours;

• Whether the final destination has sustained packet loss;

• Whether routes change at different times;

• Whether IPv4 and IPv6 paths differ significantly;

• Whether anomalous regions land on distant nodes.

Intermediate routers may rate-limit or deprioritize ICMP responses, so high packet loss shown at one hop does not necessarily mean business traffic is lost there. Base judgments on the final destination, actual TCP/TLS measurements, and multiple results, not on a single MTR screenshot to demand that the CDN change routes.

If conditions allow, combine packet capture to check whether TCP retransmission, duplicate ACK, or connection retries occur during the TLS handshake. Packet captures may contain domain names, IPs, and some connection metadata. Do not publicly upload raw files containing customer information, internal addresses, or authentication data.

Check whether you are connected to the expected CDN node

Using a CDN for a domain does not mean users will always connect to the geographically closest node. DNS scheduling, Anycast routing, carrier interconnection, and account plans can all affect the actual point of presence.

Check the current connection IP:

curl -sS -o /dev/null \
  -w 'remote_ip=%{remote_ip}\n' \
  https://www.example.com/

Then repeat tests from different networks and record:

测试地区
运营商
解析IP
实际连接IP
TCP耗时
TLS耗时
HTTP版本

Pay particular attention to:

• DNS resolution results and the actual connection IP are not always the same;

• IP geolocation databases may contain errors;

• A node IP's registered location is not equal to where the server is actually deployed;

• A low ping does not mean TLS, TTFB, and page load will necessarily be fast;

• The same IP may access different nodes in different regions through Anycast.

What really matters is actual connection performance on target users' networks, not judging node distance from an IP ownership database.

Check enterprise proxies, antivirus software, and TLS inspection devices

If ordinary home networks are normal and only corporate, school, or specific institutional networks show high TLS time, check middleboxes.

Enterprise security gateways may perform TLS inspection:

用户
  ↓ TLS连接一
企业代理或安全网关
  ↓ TLS连接二
CDN节点

The certificate users see may be reissued by an internal enterprise CA, and handshake time may also include proxy processing, policy lookups, or a second connection.

You can check the certificate issuer in the browser. If the issuer is not the public CA normally used by the website, but an enterprise, school, or security software name, the connection may be passing through TLS inspection.

Do not ask users to disable antivirus software, corporate proxies, or certificate validation just to reduce handshake time. The correct approach is for network administrators to check proxy capacity, policies, and certificate deployment, and to use controlled test devices to compare direct connection results.

Distinguish edge TLS from origin TLS

When users access a CDN, there may actually be two independent TLS handshakes:

用户 ── TLS握手一 ── CDN边缘节点
CDN边缘节点 ── TLS握手二 ── 源站

Public website speed tests and browser developer tools usually observe the first segment, the handshake from the user to the CDN edge node.

Metrics such as 'origin connection time,' 'Origin TLS Time,' or similar in the CDN console may observe the second segment. The two cannot be compared directly:

• User-to-CDN slow: focus on node distance, carrier routing, TLS version, and client network;

• CDN-to-origin slow: focus on origin region, origin fetch path, origin load, certificates, and ports;

• Public TLS normal but TTFB high: may be CDN processing, cache MISS, or slow origin fetch;

• Public TLS high but origin normal: the problem is more likely between the user and the CDN.

For certificate, SNI, and port configuration on the second connection, see the pending-review articleHTTP or HTTPS for CDN origin fetch? How to choose certificates, SNI, and ports.

HTTP/2, HTTP/3, and TLS times cannot be compared laterally

HTTP/1.1 and HTTP/2 usually run over TCP and TLS, while HTTP/3 is based on QUIC and integrates TLS 1.3 into connection establishment.

Therefore, different tools may use different definitions for HTTP/3's 'TCP time,' 'TLS time,' and 'connection time.' Some tools may count QUIC connection establishment as TLS, and some fields may show 0 or cannot be separated independently.

To compare HTTP/2 and HTTP/3, record:

协议版本
完整连接建立时间
TTFB
总耗时
失败率
测试地区
是否首次连接

Do not simply compare a TLS field in HTTP/2 directly with the same-named field in HTTP/3. The protocol stages differ, and metrics with the same name may not use the same measurement boundaries.

HTTP/3 is not necessarily faster on every network. If UDP is restricted, QUIC path quality is poor, or middlebox compatibility is poor, browsers may fall back to HTTP/2, and first-connection time may fluctuate instead.

When switching CDNs may actually be effective

After completing the checks above, if the following evidence appears, switching CDNs has clear testing value:

• The target market has long been connecting to distant nodes;

• Certain key carriers consistently have route detours or high packet loss;

• The current CDN lacks suitable nodes in major user regions;

• TLS times for P50 and P95 across multiple regions are clearly higher than those of a candidate CDN;

• The current CDN does not support the TLS 1.3, HTTP/3, or session resumption capabilities required by the business;

• Stable, reproducible handshake latency spikes occur during node peak hours;

• The vendor cannot provide sufficient diagnostic logs or improvement plans.

If the problem comes from the following causes, switching CDNs directly may not be effective:

• Local corporate proxy or security software;

• Incorrect IPv6 routing or domain configuration;

• The speed test tool mislabels cumulative time as TLS time;

• Abnormal client device performance;

• Certificate chain or domain configuration errors;

• Slow origin TLS is misjudged as slow user-side edge TLS;

• Drawing conclusions from only one test or a single region.

Before switching, it is best to configure a test domain on the candidate CDN, use the same certificate policy, same test targets, and similar cache state, and run a comparative test against real user regions for a period of time. Comparing only vendor marketing data cannot prove actual results after migrating the business domain.

A directly executable review checklist

Before deciding whether to switch CDNs, confirm in order:

□ TLS指标是否为独立阶段，而不是累计时间
□ time_appconnect是否减去了time_connect
□ 是否使用新的独立连接重复测试
□ IPv4和IPv6是否分别测试
□ 是否覆盖主要地区和运营商
□ 是否同时查看P50、P95和失败率
□ TLS 1.2与TLS 1.3是否分别测试
□ 证书SAN、中间链和验证结果是否正常
□ 是否检查OCSP Stapling，但没有把它当成唯一结论
□ 是否排除企业代理和TLS检查设备
□ 是否检查网络丢包、绕行和节点位置
□ 是否区分用户到CDN与CDN到源站的TLS
□ 是否用测试域名与候选CDN进行同条件对照

Only when the anomaly can be consistently reproduced in the target region and the evidence points to node coverage, route quality, or CDN edge TLS capability is switching CDNs a justified solution.

FAQ

What TLS handshake time is considered normal?

There is no uniform value applicable to all networks worldwide. TLS time is affected by network round trips between client and node, protocol version, packet loss, and device performance. Same-city access and intercontinental access cannot use the same threshold. It is more appropriate to compare with TCP time, historical baselines, and candidate CDNs in the same region.

Is time_appconnect the TLS handshake time?

It is not the pure TLS stage. curl'stime_appconnectis the cumulative time from request start to completion of application-layer handshakes such as TLS. The approximate TLS stage time is usually calculated withtime_appconnect - time_connect.

Why is TLS slow the first time but faster after refresh?

Subsequent visits may reuse an existing connection or use TLS session resumption. DNS, system caches, and network paths may also already be established. To judge first-visit experience, test with an independent new connection, not just repeated browser refreshes.

Will enabling TLS 1.3 definitely solve slow handshakes?

Not necessarily. TLS 1.3 can reduce the network round trips required for a full handshake, but if the main problem is route detours, packet loss, enterprise proxy, or connecting to a distant node, it may still be slow after enabling the protocol.

Does a shorter certificate chain always make TLS faster?

Certificate chain size affects handshake transmission volume, but it is only one factor. A normal complete certificate chain should not have intermediate certificates arbitrarily removed just to make it smaller, as that may cause validation failures on some clients. Remove unnecessary duplicate certificates, but do not break the trust chain.

Ping is low, why is TLS still high?

Ping uses ICMP and does not perform TCP connection, TLS certificate exchange, or cipher negotiation. A low ping only means some type of network probe has fast round-trip time; it does not prove the HTTPS handshake will be fast.

After enabling HTTP/3 on the CDN, why doesn't the speed test tool show TLS time?

HTTP/3 is based on QUIC, and TLS 1.3 is integrated into QUIC connection establishment. Some speed test tools cannot split stages the way they do for TCP plus TLS, so it may show 0, be missing, or be grouped under connection time. Check the tool's measurement definitions.

Only IPv6 TLS time is high. Should I disable the AAAA record?

Do not immediately delete the AAAA record. First confirm whether IPv6 resolves to the correct CDN, whether there are regional routing anomalies, and whether the vendor can adjust scheduling. Temporarily disabling the abnormal IPv6 entry point may be used for controlled loss limitation, but the long-term solution should be to fix the IPv6 path, not abandon IPv6 by default.