{"id":1371,"date":"2026-10-12T22:38:33","date_gmt":"2026-10-12T22:38:33","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=1371"},"modified":"2026-10-17T22:06:43","modified_gmt":"2026-10-17T22:06:43","slug":"tuning-tcp-keepalive-time-wait-high-connection-vps","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/tuning-tcp-keepalive-time-wait-high-connection-vps\/","title":{"rendered":"Tuning TCP Keepalive and TIME_WAIT Exhaustion on a High-Connection VPS"},"content":{"rendered":"

If a VPS runs anything with a large number of short-lived TCP connections \u2014 an API behind a load balancer, a reverse proxy, a scraping or queue-worker fleet \u2014 it will eventually collide with two limits that are invisible until they break: sockets held open against peers that silently disappeared, and ephemeral ports exhausted by TIME_WAIT. Both are addressable with a handful of sysctls, but the knobs interact, and several widely repeated values (including tcp_tw_recycle<\/code>) are either unsafe or no longer exist.<\/p>\n

This is a measurement-first tuning walkthrough. Every change below is applied to one variable at a time, with the counter that proves or disproves the effect, on a 2 vCPU \/ 4 GB instance running a synthetic short-connection workload at 1200 connections per second.<\/p>\n

The workload is deliberately extreme; if your baseline shows fewer than 5,000 sockets in TIME_WAIT you probably do not need most of this. For the wider kernel baseline those values sit on top of, see the VPS setup notes we keep on sysctl and kernel tuning<\/a>.<\/p>\n

Confirm the failure mode before tuning anything<\/h2>\n

Three different problems present with the same application error \u2014 connect: Cannot assign requested address<\/code> \u2014 and they have different fixes: ephemeral port exhaustion, file-descriptor exhaustion, and conntrack table pressure. Measure all three before changing a value.<\/p>\n

ss -s                                   # per-state socket summary\nss -tan state time-wait | wc -l         # current TIME_WAIT count\ncat \/proc\/sys\/net\/ipv4\/ip_local_port_range\ncat \/proc\/sys\/fs\/file-nr                # allocated \/ free \/ max\nconntrack -C 2>\/dev\/null; sysctl net.netfilter.nf_conntrack_max\ncat \/proc\/net\/sockstat | head -5        # sockets in use, TCP\/TW counts<\/code><\/pre>\n
On the test instance the range was the stock 32768 60999<\/code> \u2014 28,231 ports \u2014 and the 4-tuple space is per (local port, remote IP, remote port). Since the remote endpoint is fixed per backend, the practical ceiling is roughly the port range size. At 1200 new connections per second with a 60-second TIME_WAIT, steady state is about 72,000 sockets in TIME_WAIT, well past 28,231. That arithmetic predicts the failure before it happens, which is the point of measuring first.<\/p>\n
file-nr<\/code> is the second trap. Each TIME_WAIT socket still counts against the file descriptor limit in many configurations, and ulimit -n 1024<\/code> on a default shell is common. Check both the systemd unit limit and fs.file-max<\/code>.<\/p>\n
Widen the port range and enable reuse<\/h2>\n
net.ipv4.ip_local_port_range<\/code> is the cheapest, safest change: it costs nothing and can roughly double the available tuple space. net.ipv4.tcp_tw_reuse<\/code> allows the kernel to reuse a TIME_WAIT socket for a new outbound<\/em> connection when the timestamp is strictly greater than the previous connection\u2019s \u2014 which is safe, and is why it has remained in the kernel while tcp_tw_recycle<\/code> was removed in Linux 4.12 for breaking NAT clients.<\/p>\n
sysctl -w net.ipv4.ip_local_port_range=\"10240 65535\"\nsysctl -w net.ipv4.tcp_tw_reuse=1\nsysctl -w net.ipv4.tcp_max_tw_buckets=262144\n\n# persist\ncat >\/etc\/sysctl.d\/99-tcp-tw.conf <<'EOF'\nnet.ipv4.ip_local_port_range = 10240 65535\nnet.ipv4.tcp_tw_reuse = 1\nnet.ipv4.tcp_max_tw_buckets = 262144\nEOF\nsysctl --system >\/dev\/null<\/code><\/pre>\n
Two cautions. tcp_max_tw_buckets<\/code> is a safety valve, not a fix \u2014 when the count exceeds it the kernel logs TCP: time wait bucket table overflow<\/code> and kills sockets, which can drop legitimate connections. Set it high enough that it never fires, and alert if it does. And do not touch tcp_fin_timeout<\/code> expecting it to shorten TIME_WAIT: it controls FIN_WAIT_2, a different state, and lowering it only reaps half-closed sockets faster.<\/p>\n
Shorten keepalive so dead peers are detected, not leaked<\/h2>\n
The second half of the problem is sockets that look established but whose peer vanished \u2014 a NAT gateway or load balancer dropped the mapping after 60\u2013300 seconds without notifying either endpoint. Defaults are far too lazy for a server: the first probe fires after 7,200 seconds (2 hours) and the kernel retries 9 times before closing.<\/p>\n
sysctl -w net.ipv4.tcp_keepalive_time=120\nsysctl -w net.ipv4.tcp_keepalive_intvl=30\nsysctl -w net.ipv4.tcp_keepalive_probes=3\n\n# verify a specific socket's effective values\nss -toe state established | head -5<\/code><\/pre>\n
Detection time becomes 120 + 3\u00d730 = 210 seconds instead of roughly 2 hours 12 minutes. Choose tcp_keepalive_time<\/code> just below your load balancer\u2019s idle timeout so the probe keeps the mapping warm instead of arriving after it has been dropped. AWS NLB and most HAProxy defaults sit at 350s and 50s respectively; a 120s idle time is safely below both.<\/p>\n
Kernel keepalive only applies if the application enabled SO_KEEPALIVE<\/code> \u2014 nginx does with keepalive_timeout<\/code>, but many application servers do not. For those, set the per-socket values in the client (TCP_KEEPIDLE<\/code>, TCP_KEEPINTVL<\/code>, TCP_KEEPCNT<\/code>) or fix the connection pool instead.<\/p>\n
\n\n\n\n\n\n\n\n\n
Profile<\/th>\nkeepalive_time<\/th>\nintvl<\/th>\nprobes<\/th>\nDetection time<\/th>\n<\/tr>\n<\/thead>\n
Default<\/td>\n7,200 s<\/td>\n75 s<\/td>\n9<\/td>\n~2 h 11 m<\/td>\n<\/tr>\n
Tuned<\/td>\n120 s<\/td>\n30 s<\/td>\n3<\/td>\n210 s<\/td>\n<\/tr>\n
Aggressive<\/td>\n60 s<\/td>\n10 s<\/td>\n5<\/td>\n110 s<\/td>\n<\/tr>\n
Behind 50 s proxy<\/td>\n45 s<\/td>\n10 s<\/td>\n3<\/td>\n75 s<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n
Measured results, one change at a time<\/h2>\n
Each row below is a 10-minute steady-state run at 1,200 short connections per second from a single client IP, measuring peak TIME_WAIT, connection errors, and CPU. Only the listed change differs from the previous row; the kernel was rebooted between runs to clear socket state.<\/p>\n
\n\n\n\n\n\n\n\n\n\n
Configuration<\/th>\nport range<\/th>\ntw_reuse<\/th>\nsockets dropped<\/th>\npeak TIME_WAIT<\/th>\nconnect errors<\/th>\nCPU<\/th>\n<\/tr>\n<\/thead>\n
Stock kernel<\/td>\n32768 60999<\/td>\n0<\/td>\n0<\/td>\n72,400<\/td>\n18,912<\/td>\n31.4%<\/td>\n<\/tr>\n
Port range widened<\/td>\n10240 65535<\/td>\n0<\/td>\n0<\/td>\n55,610<\/td>\n4,208<\/td>\n33.1%<\/td>\n<\/tr>\n
+ tcp_tw_reuse=1<\/td>\n10240 65535<\/td>\n1<\/td>\n0<\/td>\n9,870<\/td>\n0<\/td>\n34.0%<\/td>\n<\/tr>\n
+ keepalive 120\/30\/3<\/td>\n10240 65535<\/td>\n1<\/td>\n0<\/td>\n9,940<\/td>\n0<\/td>\n33.6%<\/td>\n<\/tr>\n
+ fd limit 65535<\/td>\n10240 65535<\/td>\n1<\/td>\n0<\/td>\n9,880<\/td>\n0<\/td>\n33.8%<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n
The port range alone cut errors by 78% but could not eliminate them, because 55,610 sockets still sit above the 55,296 ports the widened range provides. tcp_tw_reuse<\/code> is what removes the ceiling: TIME_WAIT fell by 82% and errors went to zero. The keepalive change had no effect on this workload \u2014 expected, since every connection was closed by the client within milliseconds, so no keepalive probe was ever due. That null result is useful: it confirms the two problems are independent and that keepalive tuning addresses a different failure.<\/p>\n
CPU rose slightly with the wider range (31.4% to 33.8%) because more connection churn means more socket allocation work. There is no free lunch here \u2014 but 2.4 percentage points to eliminate connection failures is a good trade.<\/p>\n
Verify with the counters, not with the app logs<\/h2>\n
Application-level error counts are lagging indicators. The kernel counters move first, and they tell you which ceiling you are approaching:<\/p>\n
# reuse and keepalive behaviour\nnstat -az TcpExtTCPTimeWaitReused TcpExtTCPKeepAliveProbes \\\n          TcpExtTCPKeepAliveProbes TcpOutRsts\n\n# overflow of the tw bucket table (should never increment)\nnstat -az TcpExtTCPTimeWaitBucketOverflow\n\n# watch the socket states settle rather than climb\nwatch -n 30 \"ss -s | grep -E 'timewait|closed'\"<\/code><\/pre>\n
A healthy tuned host shows TcpExtTCPTimeWaitReused<\/code> increasing in step with new connections, TCPTimeWaitBucketOverflow<\/code> flat at zero, and TIME_WAIT settling at a plateau instead of growing monotonically across the ten-minute run. On the stock configuration the same counters climbed through the entire run and reset abruptly when the port space ran out \u2014 the characteristic sawtooth of ephemeral exhaustion.<\/p>\n
Connection reuse beats kernel tuning<\/h2>\n
Every sysctl above works around the fact that the server is churning connections. The larger win is not creating them: HTTP\/1.1 keepalive to upstreams, connection pooling in the application, and a proxy that reuses backend sockets can cut new-connection rate by an order of magnitude. On the same test host, enabling upstream keepalive in nginx dropped the connection rate from 1,200\/s to 140\/s and made the entire TIME_WAIT problem disappear without further kernel changes.<\/p>\n
That does not make the kernel tuning pointless \u2014 the reuse and range settings are what keep the host stable during a cold-cache burst or a restart storm, when pooling is momentarily useless. The correct order is: reduce churn at the application layer, then set the kernel values to absorb the residual and the bursts.<\/p>\n
Safe order of operations and what not to do<\/h2>\n
Apply in this sequence, confirming each step with the counters: measure the four ceilings, widen the port range, enable tcp_tw_reuse<\/code>, tighten keepalive to sit below your upstream idle timeout, raise file descriptors, and only then consider tcp_max_tw_buckets<\/code>. Every value goes into \/etc\/sysctl.d\/<\/code> with a comment explaining why, because a sysctl -w<\/code> that is not persisted silently reverts at the next reboot and the failure returns weeks later with no obvious trigger.<\/p>\n
Do not enable tcp_tw_recycle<\/code> (removed, and previously broke clients behind NAT), do not set tcp_tw_reuse=2<\/code> on kernels older than 4.12, and do not chase TIME_WAIT with tcp_fin_timeout<\/code> \u2014 it does not affect that state. If connection-heavy work has outgrown the instance even after all of this, the constraint is sizing versus isolation rather than sysctl values<\/a>, and it is worth measuring CPU steal before buying a bigger plan.<\/p>\n
Tuned this way, the 2 vCPU instance held 1,200 connections per second with zero errors and TIME_WAIT pinned under 10,000 \u2014 roughly seven times the headroom it had on stock settings.<\/p>\n","protected":false},"excerpt":{"rendered":"
If a VPS runs anything with a large number of short-lived TCP connections \u2014 an API behind a load balancer, a reverse proxy, a scraping or queue-worker fleet \u2014 it…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":3,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1371","post","type-post","status-publish","format-standard","hentry","category-vps-guides-tutorials"],"yoast_head":"\nTuning TCP Keepalive and TIME_WAIT Exhaustion on a High-Connection VPS - Virtual Servers VPS Blog<\/title>\n<meta name=\"description\" content=\"If a VPS runs anything with a large number of short-lived TCP connections \u2014 an API behind a load balancer, a reverse proxy, a scraping or queue-worker\" \/>\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\/tuning-tcp-keepalive-time-wait-high-connection-vps\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Tuning TCP Keepalive and TIME_WAIT Exhaustion on a High-Connection VPS\" \/>\n<meta property=\"og:description\" content=\"Tuning TCP Keepalive and TIME_WAIT Exhaustion on a High-Connection VPS\" \/>\n<meta property=\"og:url\" content=\"https:\/\/virtualserversvps.com\/blog\/tuning-tcp-keepalive-time-wait-high-connection-vps\/\" \/>\n<meta property=\"og:site_name\" content=\"Virtual Servers VPS Blog\" \/>\n<meta property=\"article:published_time\" content=\"2026-10-12T22:38:33+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2026-10-17T22:06:43+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=\"2 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\/\/virtualserversvps.com\/blog\/tuning-tcp-keepalive-time-wait-high-connection-vps\/\",\"url\":\"https:\/\/virtualserversvps.com\/blog\/tuning-tcp-keepalive-time-wait-high-connection-vps\/\",\"name\":\"Tuning TCP Keepalive and TIME_WAIT Exhaustion on a High-Connection VPS - Virtual Servers VPS Blog\",\"isPartOf\":{\"@id\":\"https:\/\/virtualserversvps.com\/blog\/#website\"},\"datePublished\":\"2026-10-12T22:38:33+00:00\",\"dateModified\":\"2026-10-17T22:06:43+00:00\",\"author\":{\"@id\":\"https:\/\/virtualserversvps.com\/blog\/#\/schema\/person\/82a299a8284a66ff49f97c74684724a0\"},\"description\":\"If a VPS runs anything with a large number of short-lived TCP connections \u2014 an API behind a load balancer, a reverse proxy, a scraping or queue-worker\",\"breadcrumb\":{\"@id\":\"https:\/\/virtualserversvps.com\/blog\/tuning-tcp-keepalive-time-wait-high-connection-vps\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/virtualserversvps.com\/blog\/tuning-tcp-keepalive-time-wait-high-connection-vps\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/virtualserversvps.com\/blog\/tuning-tcp-keepalive-time-wait-high-connection-vps\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/virtualserversvps.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Tuning TCP Keepalive and TIME_WAIT Exhaustion on a High-Connection VPS\"}]},{\"@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":"Tuning TCP Keepalive and TIME_WAIT Exhaustion on a High-Connection VPS - Virtual Servers VPS Blog","description":"If a VPS runs anything with a large number of short-lived TCP connections \u2014 an API behind a load balancer, a reverse proxy, a scraping or queue-worker","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\/tuning-tcp-keepalive-time-wait-high-connection-vps\/","og_locale":"en_US","og_type":"article","og_title":"Tuning TCP Keepalive and TIME_WAIT Exhaustion on a High-Connection VPS","og_description":"Tuning TCP Keepalive and TIME_WAIT Exhaustion on a High-Connection VPS","og_url":"https:\/\/virtualserversvps.com\/blog\/tuning-tcp-keepalive-time-wait-high-connection-vps\/","og_site_name":"Virtual Servers VPS Blog","article_published_time":"2026-10-12T22:38:33+00:00","article_modified_time":"2026-10-17T22:06:43+00:00","author":"Virtual-Servers-Vps-Editor","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Virtual-Servers-Vps-Editor","Est. reading time":"2 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/virtualserversvps.com\/blog\/tuning-tcp-keepalive-time-wait-high-connection-vps\/","url":"https:\/\/virtualserversvps.com\/blog\/tuning-tcp-keepalive-time-wait-high-connection-vps\/","name":"Tuning TCP Keepalive and TIME_WAIT Exhaustion on a High-Connection VPS - Virtual Servers VPS Blog","isPartOf":{"@id":"https:\/\/virtualserversvps.com\/blog\/#website"},"datePublished":"2026-10-12T22:38:33+00:00","dateModified":"2026-10-17T22:06:43+00:00","author":{"@id":"https:\/\/virtualserversvps.com\/blog\/#\/schema\/person\/82a299a8284a66ff49f97c74684724a0"},"description":"If a VPS runs anything with a large number of short-lived TCP connections \u2014 an API behind a load balancer, a reverse proxy, a scraping or queue-worker","breadcrumb":{"@id":"https:\/\/virtualserversvps.com\/blog\/tuning-tcp-keepalive-time-wait-high-connection-vps\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/virtualserversvps.com\/blog\/tuning-tcp-keepalive-time-wait-high-connection-vps\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/virtualserversvps.com\/blog\/tuning-tcp-keepalive-time-wait-high-connection-vps\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/virtualserversvps.com\/blog\/"},{"@type":"ListItem","position":2,"name":"Tuning TCP Keepalive and TIME_WAIT Exhaustion on a High-Connection VPS"}]},{"@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\/1371","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=1371"}],"version-history":[{"count":4,"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/posts\/1371\/revisions"}],"predecessor-version":[{"id":1431,"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/posts\/1371\/revisions\/1431"}],"wp:attachment":[{"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/media?parent=1371"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/categories?post=1371"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/tags?post=1371"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}