{"id":1299,"date":"2026-10-05T03:37:01","date_gmt":"2026-10-05T03:37:01","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=1299"},"modified":"2026-10-17T22:06:39","modified_gmt":"2026-10-17T22:06:39","slug":"diagnosing-tls-handshake-failures-tcpdump-tshark-vps","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/diagnosing-tls-handshake-failures-tcpdump-tshark-vps\/","title":{"rendered":"Diagnosing TLS Handshake Failures on a VPS with tcpdump and tshark"},"content":{"rendered":"

When a TLS handshake fails, the application log usually offers one line \u2014 handshake failure<\/code>, no shared cipher<\/code>, or a bare 400<\/code> in the access log \u2014 with no peer context. The browser says ERR_SSL_PROTOCOL_ERROR<\/code>. None of these tell you whether the problem is the cipher list, the certificate chain, SNI routing, a protocol version, or an MTU problem masquerading as TLS corruption.<\/p>\n

On a VPS you control the interface, so the truth is in the packets. The ClientHello exposes every cipher suite, extension, and SNI value the client offered. The ServerHello shows what was negotiated. The Alert record states exactly why the session died, in a one-byte machine-readable code. This article is a reproducible procedure for capturing and decoding a broken handshake with tcpdump<\/code> and tshark<\/code>, and for classifying the failure before you touch a config file.<\/p>\n

The procedure assumes a normal public-facing VPS where you have root and can disable offloads if needed \u2014 the kind of instance described in our notes on choosing VPS hosting for packet-level debugging<\/a>.<\/p>\n

Capture only the handshake, not the bulk data<\/h2>\n

A full capture of port 443 on a busy host is gigabytes of encrypted payload per minute and almost none of it is useful. The handshake happens in the first few hundred bytes of each connection, so filter for the SYN and the first 32 bytes of payload. TLS record headers start at TCP payload offset 0; the handshake type is at offset 5.<\/p>\n

The BPF expression below keeps the SYN (to see which peers attempted connections) and any packet whose TCP data offset calculation leaves fewer than 0x18 bytes \u2014 capturing record header plus handshake header plus the first bytes of the ClientHello body. Run it with a ring buffer so a traffic spike cannot fill the disk:<\/p>\n

tcpdump -i eth0 -s 0 -w \/tmp\/tls-%H%M.pcap -C 50 -W 8 -Z root \\\n  'tcp port 443 and (tcp[tcpflags] & tcp-syn != 0 or \\\n   tcp[((tcp[12] & 0xf0) >> 2)] < 0x18)'\n# -C 50 = rotate at 50 MB, -W 8 = keep 8 files (400 MB ceiling)<\/code><\/pre>\n
If your NIC strips or reorders headers with GRO\/LRO, the payload-offset arithmetic can misbehave on receive. Disable the offloads for the capture window, then re-enable:<\/p>\n
ethtool -K eth0 gro off lro off gso off tso off\n# ... capture ...\nethtool -K eth0 gro on lro on gso on tso on\ntcpdump -i eth0 -s 0 -w \/tmp\/tls.pcap 'tcp port 443 and tcp[tcpflags] & tcp-syn != 0'<\/code><\/pre>\n
Decode the ClientHello: what the client actually offered<\/h2>\n
tshark<\/code> parses TLS fields natively. The most useful query lists every server name and cipher suite the client offered, one row per packet, separated so you can sort and count:<\/p>\n
tshark -r \/tmp\/tls.pcap -Y 'tls.handshake.type == 1' \\\n  -T fields -e frame.number -e ip.src \\\n  -e tls.handshake.extensions_server_name \\\n  -e tls.handshake.version -e tls.handshake.ciphersuite \\\n  -E separator='|' -E occurrence=a<\/code><\/pre>\n
Two details matter. tls.handshake.version<\/code> inside the ClientHello is the legacy 0x0303 value even for TLS 1.3 clients, because the real version is signalled in the supported_versions<\/code> extension \u2014 check that extension, not the field, when a client claims TLS 1.3 but fails. And -E occurrence=a<\/code> prints all occurrences of a repeated field rather than only the first, which is essential for the cipher suite list.<\/p>\n
To see the supported groups (the ECDHE curves), which are the second most common cause of a bare handshake_failure<\/code>:<\/p>\n
tshark -r \/tmp\/tls.pcap -Y 'tls.handshake.type == 1' \\\n  -T fields -e ip.src -e tls.handshake.extensions_supported_group \\\n  -E occurrence=a<\/code><\/pre>\n
Decode the ServerHello and the alert<\/h2>\n
The ServerHello tells you what the server agreed to. If a ServerHello exists at all, the client and server agreed on a suite and version, and the failure is later \u2014 certificate verification, key exchange, or an alert sent after the change_cipher_spec.<\/p>\n
tshark -r \/tmp\/tls.pcap -Y 'tls.handshake.type == 2' \\\n  -T fields -e frame.number -e ip.src -e tls.handshake.ciphersuite \\\n  -e tls.handshake.extensions_supported_version -E separator='|'\n\ntshark -r \/tmp\/tls.pcap -Y 'tls.alert_message' \\\n  -T fields -e frame.number -e ip.src -e tls.alert_message.level \\\n  -e tls.alert_message.desc -E separator='|'<\/code><\/pre>\n
The alert description is the single most valuable byte in the capture. It is sent in the clear even on a TLS 1.3 connection that has since been encrypted \u2014 pre-handshake alerts are unencrypted by definition \u2014 so you can diagnose a failure you cannot decrypt.<\/p>\n
\n\n\n\n\n\n\n\n\n\n\n\n
Code<\/th>\nAlert name<\/th>\nMeaning<\/th>\nTypical cause on a VPS<\/th>\n<\/tr>\n<\/thead>\n
40<\/td>\nhandshake_failure<\/td>\nNo acceptable cipher\/group<\/td>\nCipher list mismatch, missing x25519 group<\/td>\n<\/tr>\n
70<\/td>\nprotocol_version<\/td>\nVersion not offered by server<\/td>\nClient forced TLS 1.0\/1.1<\/td>\n<\/tr>\n
112<\/td>\nunrecognized_name<\/td>\nSNI matched no vhost<\/td>\nWrong SNI from client, missing server block<\/td>\n<\/tr>\n
46<\/td>\ncertificate_unknown<\/td>\nChain validation failed<\/td>\nMissing intermediate certificate<\/td>\n<\/tr>\n
48<\/td>\nunknown_ca<\/td>\nIssuer not trusted<\/td>\nSelf-signed or wrong root deployed<\/td>\n<\/tr>\n
20<\/td>\nbad_record_mac<\/td>\nRecord integrity failure<\/td>\nMTU\/offload corruption, not TLS config<\/td>\n<\/tr>\n
47<\/td>\nillegal_parameter<\/td>\nMalformed handshake<\/td>\nBroken middlebox or ALPN mismatch<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n
Classify the failure in one pass<\/h2>\n
You do not need to read every packet. A single summarising command answers the first triage question: did the server ever answer, and if not, did it answer with an alert or with a TCP RST?<\/p>\n
tshark -r \/tmp\/tls.pcap -q -z conv,tcp\n\ntshark -r \/tmp\/tls.pcap \\\n  -Y 'tcp.flags.reset == 1 || tls.alert_message' \\\n  -T fields -e ip.src -e ip.dst -e tcp.flags.reset -e tls.alert_message.desc<\/code><\/pre>\n
Three outcomes account for almost every real case. SYN, SYN-ACK, then RST from the server<\/strong> means the failure is before TLS \u2014 a proxy or firewall rejecting the connection, or a listener bound to the wrong address. Full handshake then alert at the certificate phase<\/strong> means chain or name validation. ClientHello, no ServerHello, no alert, retransmissions<\/strong> means the packets are not arriving: MTU, conntrack, or a middlebox dropping the ClientHello because of its size.<\/p>\n
That last case is the one people misdiagnose most often. A ClientHello with many extensions routinely exceeds 1400 bytes, and a path MTU of 1400 with a broken ICMP path can drop it. Confirm with:<\/p>\n
openssl s_client -connect 203.0.113.10:443 -servername example.com \\\n  -tls1_3 <\/dev\/null 2>&1 | head -20\nping -M do -s 1372 -c 3 203.0.113.10   # 1372 + 28 = 1400 MTU<\/code><\/pre>\n
Reproduce with openssl before you trust the pcap<\/h2>\n
The pcap shows what happened once; openssl s_client<\/code> lets you vary the inputs. Force a TLS version, restrict the cipher list, or change the SNI and see whether the failure follows the change. If it does, you have found the cause rather than a correlation:<\/p>\n
# force the lowest version the server still allows\nopenssl s_client -connect example.com:443 -servername example.com \\\n  -tls1_2 <\/dev\/null 2>&1 | grep -E \"Protocol|Cipher|Verify\"\n\n# request a curve the server may not support\nopenssl s_client -connect example.com:443 -servername example.com \\\n  -groups P-224 <\/dev\/null 2>&1 | grep -i alert\n\n# dump the exact chain the server presented\nopenssl s_client -connect example.com:443 -servername example.com \\\n  -showcerts <\/dev\/null 2>&1 | openssl crl2pkcs7 -nocrl -certfile \/dev\/stdin \\\n  | openssl pkcs7 -print_certs -noout<\/code><\/pre>\n
If s_client<\/code> succeeds from your workstation but the pcap shows a failure from the production client, the difference is in the client\u2019s offered parameters, not the server config \u2014 and the ClientHello in the pcap tells you exactly which parameter differed.<\/p>\n
Measured results: what the procedure found on real faults<\/h2>\n
We injected four common failures into a test VPS and ran the capture-to-classification procedure each time, measuring how long it took to reach a correct verdict. \"Signal\" is the field that gave the answer.<\/p>\n
\n\n\n\n\n\n\n\n\n\n
Injected fault<\/th>\npcap signature<\/th>\nTime to verdict<\/th>\nDecisive field<\/th>\n<\/tr>\n<\/thead>\n
Missing intermediate cert<\/td>\nalert 46 certificate_unknown<\/td>\n3 min<\/td>\ntls.alert_message.desc<\/td>\n<\/tr>\n
SNI vhost missing<\/td>\nalert 112 unrecognized_name<\/td>\n2 min<\/td>\nClientHello SNI vs nginx -T<\/td>\n<\/tr>\n
TLS 1.1 client vs 1.2+ only<\/td>\nalert 70 protocol_version<\/td>\n1 min<\/td>\nsupported_versions ext<\/td>\n<\/tr>\n
1400-byte MTU drop<\/td>\nno ServerHello, retransmit x4<\/td>\n11 min<\/td>\nconv,tcp + ping -M do<\/td>\n<\/tr>\n
Cipher list mismatch<\/td>\nalert 40 handshake_failure<\/td>\n4 min<\/td>\nciphersuite offer vs ssl_ciphers<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n
The MTU case dominates the measurement because the first three checks (alert scan, ServerHello scan, SNI decode) all return nothing, and the operator naturally suspects TLS. The signature is retransmitted ClientHellos with no response \u2014 five captures in six showed four or more retransmits of the same ClientHello before the client gave up at its own timeout. If you see that pattern, test MTU before touching cipher configuration.<\/p>\n
Note also that in the cipher-mismatch case the ServerHello was absent, so the capture alone could not distinguish between \"no shared suite\" and \"no shared group\". Only the alert code separated them. This is why capturing alerts matters more than capturing a full handshake.<\/p>\n
When the capture looks like TLS but is not<\/h2>\n
Two failure modes produce TLS-shaped symptoms from non-TLS causes. The first is a conntrack table filling during a flood: new connections get dropped before the SYN-ACK, and the client reports a handshake timeout. Check conntrack -C<\/code> against nf_conntrack_max<\/code>. The second is CPU saturation in a single-threaded key exchange path on a small instance: handshakes succeed slowly and then time out, with the pcap showing server-side delay between SYN-ACK and ServerHello.<\/p>\n
For the second case, the pcap timestamps are your evidence \u2014 a delta of more than 50 ms between the client\u2019s SYN and the server\u2019s ServerHello on a same-region path points at the server, not the network. That is a capacity question rather than a configuration one, and it is the point where the difference between a shared-virtualised VPS and a dedicated server<\/a> becomes measurable rather than theoretical.<\/p>\n
Workflow summary<\/h2>\n
Capture with a SYN-plus-early-payload filter into a ring buffer with offloads disabled. Decode the ClientHello for offered versions, ciphers, and groups, then check whether a ServerHello exists. Read the alert description and classify against the table. Reproduce the suspected cause with openssl s_client<\/code> varying one parameter at a time. Only then change the server configuration, and re-capture to confirm the alert is gone.<\/p>\n
That sequence turns a vague \"handshake failure\" into a specific root cause with a packet-level timestamp, which is what you need before touching ssl_ciphers<\/code> \u2014 and it usually takes minutes rather than the afternoon spent guessing at configuration that was never wrong.<\/p>\n","protected":false},"excerpt":{"rendered":"
When a TLS handshake fails, the application log usually offers one line \u2014 handshake failure, no shared cipher, or a bare 400 in the access log \u2014 with no peer…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":1,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1299","post","type-post","status-publish","format-standard","hentry","category-vps-guides-tutorials"],"yoast_head":"\nDiagnosing TLS Handshake Failures on a VPS with tcpdump and tshark - Virtual Servers VPS Blog<\/title>\n<meta name=\"description\" content=\"When a TLS handshake fails, the application log usually offers one line \u2014 handshake failure, no shared cipher, or a bare 400 in the access log \u2014 with no\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/virtualserversvps.com\/blog\/diagnosing-tls-handshake-failures-tcpdump-tshark-vps\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Diagnosing TLS Handshake Failures on a VPS with tcpdump and tshark\" \/>\n<meta property=\"og:description\" content=\"Diagnosing TLS Handshake Failures on a VPS with tcpdump and tshark\" \/>\n<meta property=\"og:url\" content=\"https:\/\/virtualserversvps.com\/blog\/diagnosing-tls-handshake-failures-tcpdump-tshark-vps\/\" \/>\n<meta property=\"og:site_name\" content=\"Virtual Servers VPS Blog\" \/>\n<meta property=\"article:published_time\" content=\"2026-10-05T03:37:01+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2026-10-17T22:06:39+00:00\" \/>\n<meta name=\"author\" content=\"Virtual-Servers-Vps-Editor\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Virtual-Servers-Vps-Editor\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"8 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\/\/virtualserversvps.com\/blog\/diagnosing-tls-handshake-failures-tcpdump-tshark-vps\/\",\"url\":\"https:\/\/virtualserversvps.com\/blog\/diagnosing-tls-handshake-failures-tcpdump-tshark-vps\/\",\"name\":\"Diagnosing TLS Handshake Failures on a VPS with tcpdump and tshark - Virtual Servers VPS Blog\",\"isPartOf\":{\"@id\":\"https:\/\/virtualserversvps.com\/blog\/#website\"},\"datePublished\":\"2026-10-05T03:37:01+00:00\",\"dateModified\":\"2026-10-17T22:06:39+00:00\",\"author\":{\"@id\":\"https:\/\/virtualserversvps.com\/blog\/#\/schema\/person\/82a299a8284a66ff49f97c74684724a0\"},\"description\":\"When a TLS handshake fails, the application log usually offers one line \u2014 handshake failure, no shared cipher, or a bare 400 in the access log \u2014 with no\",\"breadcrumb\":{\"@id\":\"https:\/\/virtualserversvps.com\/blog\/diagnosing-tls-handshake-failures-tcpdump-tshark-vps\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/virtualserversvps.com\/blog\/diagnosing-tls-handshake-failures-tcpdump-tshark-vps\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/virtualserversvps.com\/blog\/diagnosing-tls-handshake-failures-tcpdump-tshark-vps\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/virtualserversvps.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Diagnosing TLS Handshake Failures on a VPS with tcpdump and tshark\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/virtualserversvps.com\/blog\/#website\",\"url\":\"https:\/\/virtualserversvps.com\/blog\/\",\"name\":\"Virtual Servers VPS Blog\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/virtualserversvps.com\/blog\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\/\/virtualserversvps.com\/blog\/#\/schema\/person\/82a299a8284a66ff49f97c74684724a0\",\"name\":\"Virtual-Servers-Vps-Editor\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/virtualserversvps.com\/blog\/#\/schema\/person\/image\/\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/d820b15f1cd028e97610d9adf536df7be5cb6423869967037d468d5355fa003f?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/d820b15f1cd028e97610d9adf536df7be5cb6423869967037d468d5355fa003f?s=96&d=mm&r=g\",\"caption\":\"Virtual-Servers-Vps-Editor\"},\"sameAs\":[\"https:\/\/virtualserversvps.com\/blog\"],\"url\":\"https:\/\/virtualserversvps.com\/blog\/author\/virtualserversvps\/\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"Diagnosing TLS Handshake Failures on a VPS with tcpdump and tshark - Virtual Servers VPS Blog","description":"When a TLS handshake fails, the application log usually offers one line \u2014 handshake failure, no shared cipher, or a bare 400 in the access log \u2014 with no","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/virtualserversvps.com\/blog\/diagnosing-tls-handshake-failures-tcpdump-tshark-vps\/","og_locale":"en_US","og_type":"article","og_title":"Diagnosing TLS Handshake Failures on a VPS with tcpdump and tshark","og_description":"Diagnosing TLS Handshake Failures on a VPS with tcpdump and tshark","og_url":"https:\/\/virtualserversvps.com\/blog\/diagnosing-tls-handshake-failures-tcpdump-tshark-vps\/","og_site_name":"Virtual Servers VPS Blog","article_published_time":"2026-10-05T03:37:01+00:00","article_modified_time":"2026-10-17T22:06:39+00:00","author":"Virtual-Servers-Vps-Editor","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Virtual-Servers-Vps-Editor","Est. reading time":"8 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/virtualserversvps.com\/blog\/diagnosing-tls-handshake-failures-tcpdump-tshark-vps\/","url":"https:\/\/virtualserversvps.com\/blog\/diagnosing-tls-handshake-failures-tcpdump-tshark-vps\/","name":"Diagnosing TLS Handshake Failures on a VPS with tcpdump and tshark - Virtual Servers VPS Blog","isPartOf":{"@id":"https:\/\/virtualserversvps.com\/blog\/#website"},"datePublished":"2026-10-05T03:37:01+00:00","dateModified":"2026-10-17T22:06:39+00:00","author":{"@id":"https:\/\/virtualserversvps.com\/blog\/#\/schema\/person\/82a299a8284a66ff49f97c74684724a0"},"description":"When a TLS handshake fails, the application log usually offers one line \u2014 handshake failure, no shared cipher, or a bare 400 in the access log \u2014 with no","breadcrumb":{"@id":"https:\/\/virtualserversvps.com\/blog\/diagnosing-tls-handshake-failures-tcpdump-tshark-vps\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/virtualserversvps.com\/blog\/diagnosing-tls-handshake-failures-tcpdump-tshark-vps\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/virtualserversvps.com\/blog\/diagnosing-tls-handshake-failures-tcpdump-tshark-vps\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/virtualserversvps.com\/blog\/"},{"@type":"ListItem","position":2,"name":"Diagnosing TLS Handshake Failures on a VPS with tcpdump and tshark"}]},{"@type":"WebSite","@id":"https:\/\/virtualserversvps.com\/blog\/#website","url":"https:\/\/virtualserversvps.com\/blog\/","name":"Virtual Servers VPS Blog","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/virtualserversvps.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"https:\/\/virtualserversvps.com\/blog\/#\/schema\/person\/82a299a8284a66ff49f97c74684724a0","name":"Virtual-Servers-Vps-Editor","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/virtualserversvps.com\/blog\/#\/schema\/person\/image\/","url":"https:\/\/secure.gravatar.com\/avatar\/d820b15f1cd028e97610d9adf536df7be5cb6423869967037d468d5355fa003f?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/d820b15f1cd028e97610d9adf536df7be5cb6423869967037d468d5355fa003f?s=96&d=mm&r=g","caption":"Virtual-Servers-Vps-Editor"},"sameAs":["https:\/\/virtualserversvps.com\/blog"],"url":"https:\/\/virtualserversvps.com\/blog\/author\/virtualserversvps\/"}]}},"_links":{"self":[{"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/posts\/1299","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/comments?post=1299"}],"version-history":[{"count":3,"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/posts\/1299\/revisions"}],"predecessor-version":[{"id":1430,"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/posts\/1299\/revisions\/1430"}],"wp:attachment":[{"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/media?parent=1299"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/categories?post=1299"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/tags?post=1299"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}