{"id":1827,"date":"2025-11-14T15:11:08","date_gmt":"2025-11-14T12:11:08","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/so-where-did-all-the-ipv4-go-the-real-story-behind-exhaustion-and-price-surges\/"},"modified":"2025-11-14T15:11:08","modified_gmt":"2025-11-14T12:11:08","slug":"so-where-did-all-the-ipv4-go-the-real-story-behind-exhaustion-and-price-surges","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/so-where-did-all-the-ipv4-go-the-real-story-behind-exhaustion-and-price-surges\/","title":{"rendered":"So\u2026 Where Did All the IPv4 Go? The Real Story Behind Exhaustion and Price Surges"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><p>It started with a tiny line on a client\u2019s invoice. Not the CPU, not the storage, not even the bandwidth. A few bucks tagged onto every server for \u201cIPv4 rental.\u201d At first it felt harmless\u2014coffee money. Then a couple more apps came online, one more region spun up, a staging environment for a big launch, and suddenly that tiny line had multiplied into a real number. The team messaged me late on a Wednesday: \u201cAre we seriously paying that much just for IPs?\u201d<\/p>\n<p>Ever had that moment when something you never used to think about quietly becomes the most expensive part of your hosting bill? That\u2019s the IPv4 story in 2025. We\u2019ll talk about why IPv4 addresses are scarce, what\u2019s pushing prices up, the trade\u2011offs that surprise people (reputation and compliance are sneakily important), and the calmest path forward. I\u2019ll share some real\u2011world things I\u2019ve tried\u2014stretching a small pool of IPs without breaking SSL, making mail deliverability behave, and rolling out IPv6 without turning Friday night into a fire drill.<\/p>\n<p>Here\u2019s the thing: IPv4 Exhaustion and Price Surges aren\u2019t just headlines. They show up in architecture diagrams, in the way we design our apps, and yes, in the invoice line nobody noticed last year.<\/p>\n<div id=\"toc_container\" class=\"toc_transparent no_bullets\"><p class=\"toc_title\">\u0130&ccedil;indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#Okay_but_what_does_exhausted_IPv4_actually_mean\"><span class=\"toc_number toc_depth_1\">1<\/span> Okay, but what does \u201cexhausted IPv4\u201d actually mean?<\/a><\/li><li><a href=\"#Why_are_IPv4_prices_surging_The_quiet_factors_no_one_mentions_first\"><span class=\"toc_number toc_depth_1\">2<\/span> Why are IPv4 prices surging? The quiet factors no one mentions first<\/a><\/li><li><a href=\"#Where_the_IPv4_bill_hides_in_your_stack\"><span class=\"toc_number toc_depth_1\">3<\/span> Where the IPv4 bill hides in your stack<\/a><\/li><li><a href=\"#A_calm_playbook_to_stretch_a_small_IPv4_pool\"><span class=\"toc_number toc_depth_1\">4<\/span> A calm playbook to stretch a small IPv4 pool<\/a><\/li><li><a href=\"#Leasing_vs_buying_the_practical_checklist_no_one_hands_you\"><span class=\"toc_number toc_depth_1\">5<\/span> Leasing vs buying: the practical checklist no one hands you<\/a><\/li><li><a href=\"#The_IPv6_path_that_actually_sticks\"><span class=\"toc_number toc_depth_1\">6<\/span> The IPv6 path that actually sticks<\/a><\/li><li><a href=\"#Operational_hygiene_that_saves_real_money\"><span class=\"toc_number toc_depth_1\">7<\/span> Operational hygiene that saves real money<\/a><\/li><li><a href=\"#What_Id_do_if_I_were_starting_today\"><span class=\"toc_number toc_depth_1\">8<\/span> What I\u2019d do if I were starting today<\/a><\/li><li><a href=\"#A_few_things_that_feel_counterintuitive_but_work\"><span class=\"toc_number toc_depth_1\">9<\/span> A few things that feel counterintuitive (but work)<\/a><\/li><li><a href=\"#The_money_conversation_youll_actually_have_with_your_team\"><span class=\"toc_number toc_depth_1\">10<\/span> The money conversation you\u2019ll actually have with your team<\/a><\/li><li><a href=\"#One_last_resource_trio_if_you_want_to_go_deeper\"><span class=\"toc_number toc_depth_1\">11<\/span> One last resource trio if you want to go deeper<\/a><\/li><li><a href=\"#Wrapup_the_calm_path_through_IPv4_Exhaustion_and_Price_Surges\"><span class=\"toc_number toc_depth_1\">12<\/span> Wrap\u2011up: the calm path through IPv4 Exhaustion and Price Surges<\/a><\/li><\/ul><\/div>\n<h2 id='section-1'><span id=\"Okay_but_what_does_exhausted_IPv4_actually_mean\">Okay, but what does \u201cexhausted IPv4\u201d actually mean?<\/span><\/h2>\n<p>Think of IPv4 addresses like phone numbers in a small town. For decades, there were enough numbers for everyone. Then the town grew, the suburbs exploded, and suddenly every gate had a smart intercom. We didn\u2019t \u201cbreak the system,\u201d we simply ran out of numbers that fit the old pattern. That\u2019s IPv4. The central pools were divvied up to regional registries, who handed them out to providers, who passed them to customers. Eventually, the central pool ran dry. That didn\u2019t mean no one had IPv4 anymore\u2014just that there was no fresh supply to allocate.<\/p>\n<p>From there, the only way to get new IPv4 blocks was to <strong>buy or lease them<\/strong> from someone who already had some. That created a marketplace. And like any marketplace, it\u2019s driven by scarcity, friction, and perception. I remember when a small \/24 block felt easy to pick up and relatively cheap. Today, those same blocks trade like city parking spaces\u2014always in demand, never quite enough, and worth more than you\u2019d assume for such a small rectangle.<\/p>\n<p>If you want the official backstory, skim <a href=\"https:\/\/www.iana.org\/assignments\/ipv4-address-space\/ipv4-address-space.xhtml\" rel=\"nofollow noopener\" target=\"_blank\">IANA\u2019s note on the final IPv4 allocations<\/a>. It\u2019s not drama for drama\u2019s sake\u2014just a clear marker that the faucet is off and the buckets are being passed around.<\/p>\n<h2 id='section-2'><span id=\"Why_are_IPv4_prices_surging_The_quiet_factors_no_one_mentions_first\">Why are IPv4 prices surging? The quiet factors no one mentions first<\/span><\/h2>\n<p>Scarcity is the headline, but it\u2019s not the whole movie. In my experience, five drivers make the price arc feel relentless. First, the easy blocks are gone. What\u2019s left is scattered, sometimes messy in reputation, and frequently in sizes that don\u2019t match what teams want. Second, policies and paperwork add friction. Transfers between regions, audits, and \u201cshow me your usage plan\u201d steps don\u2019t block deals, but they slow them down and add cost. Third, reputation has become part of the price. A clean block that isn\u2019t tangled in blacklists or ancient router leaks can command a premium, especially if you send mail or run ads.<\/p>\n<p>Fourth, applications aren\u2019t rebuilt overnight. The internet speaks both IPv4 and IPv6, but lots of systems still assume IPv4 for comfort, constraint, or just the \u201cno time this sprint\u201d reality. That inertia keeps demand high. Fifth, demand is spiky. A new product launch, a cross\u2011region push, or a compliance requirement that wants an address per tenant\u2014these moments make teams buy now and ask optimization questions later. Scarcity plus urgency multiplies price pressure.<\/p>\n<p>The result isn\u2019t always dramatic on day one. It\u2019s more of a slow boil. Extra charges per IP appear across environments. Providers start rationing or pricing blocks in ways that nudge you toward NAT. And because no one wants downtime, teams pay the premium and promise themselves they\u2019ll optimize next quarter. I\u2019ve said that line, too.<\/p>\n<h2 id='section-3'><span id=\"Where_the_IPv4_bill_hides_in_your_stack\">Where the IPv4 bill hides in your stack<\/span><\/h2>\n<p>In a typical hosting setup, IPv4 costs hide in a few unglamorous corners. The most obvious is direct allocations for servers, load balancers, or firewall IPs. A surprising one is outbound services. If you handle mail, a dedicated IPv4 is almost a rite of passage, not just for isolation but for reputation management and traceability. That IP becomes your calling card in inbox land, and yes, it\u2019s worth protecting.<\/p>\n<p>Then there\u2019s the shape of your architecture. I\u2019ve seen teams hand out dedicated public IPv4s like party favors to every internal service that might someday need external access. It feels safe until the bill rolls in. A calmer pattern is to put things behind a reverse proxy or load balancer, and funnel traffic through a small, well\u2011managed set of public addresses. Internally, your services can live on private networks, and you get flexibility without scattering addresses everywhere.<\/p>\n<p>Another sneaky cost is legacy assumptions. Years ago, certain setups insisted on dedicated IPs for SSL. With SNI, that\u2019s mostly an ancient worry. But habits remain, and sometimes you\u2019ll see a team with a big list of \u201cthese sites need their own IPs for certificates.\u201d They often don\u2019t. Rechecking SSL constraints can free up addresses without changing any URLs or moving workloads.<\/p>\n<p>Mail remains a special case. Deliverability is still conservative, and having a known, warmed\u2011up IPv4 helps. If you\u2019re debating whether to share or isolate, I usually push for isolation for serious mail, but with disciplined monitoring and slow, intentional ramp\u2011ups. It\u2019s not just about avoiding blocks; it\u2019s about teaching receiving servers that you are who you say you are.<\/p>\n<h2 id='section-4'><span id=\"A_calm_playbook_to_stretch_a_small_IPv4_pool\">A calm playbook to stretch a small IPv4 pool<\/span><\/h2>\n<p>I like to start with architecture because it\u2019s where the biggest wins hide. Concentrate ingress behind a few public IPv4s using a load balancer or reverse proxy. Internally, keep services on RFC1918 private ranges and let them talk to the outside world through egress NAT. This not only reduces your public address footprint, it also cleans up security rules and logging. When you have fewer doors, you can guard them properly.<\/p>\n<p>On the web layer, combine name\u2011based virtual hosting with SNI so dozens or hundreds of domains can share the same public IPv4 without ceremony. Modern clients handle this gracefully. Certificates don\u2019t need to be a tangle either. If you\u2019re curious how to do this without drama, I wrote about <a href=\"https:\/\/www.dchost.com\/blog\/en\/haproxy-ile-l4-l7-yuk-dengeleme-nasil-sifir-kesinti-sunar-health-check-sticky-sessions-ve-tls-passthroughu-sade-sade-konusalim\/\">a clean, IPv4\u2011light load balancing stack<\/a> that handles TLS passthrough and rolling updates without downtime. The gist is: keep the number of public IPs low, keep the proxy layer smart, and let your app teams deploy without touching addressing.<\/p>\n<p>For outbound traffic, centralize egress. A small set of NAT gateways can serve a whole fleet, and with good observability you won\u2019t lose track of who did what. I\u2019ve seen teams fear NAT because of debugging nightmares from the old days. Tooling is kinder now. Tag connections, keep flow logs, and you gain more clarity than you had scattering public IPs everywhere.<\/p>\n<p>Then there\u2019s mail. If deliverability is mission critical, dedicate your IPv4s, but don\u2019t throw addresses at the problem. Warm slowly, keep your sending consistent, and protect those IPs like your good name. Keep PTR\/rDNS clean, watch feedback loops, and don\u2019t be afraid to move heavy marketing sends to a provider that lives and breathes deliverability while you keep transactional mail in\u2011house. That balance can save IPs and time.<\/p>\n<p>Finally, audit. I once reclaimed an entire \/26 just by asking why certain boxes had public addresses. Half of them were \u201ctemporary\u201d debug ports from last year. The rest were internal tools that never needed to be on the edge. You\u2019ll be amazed what a friendly inventory round will uncover.<\/p>\n<h2 id='section-5'><span id=\"Leasing_vs_buying_the_practical_checklist_no_one_hands_you\">Leasing vs buying: the practical checklist no one hands you<\/span><\/h2>\n<p>When you step into the market, treat IPv4 like real estate. Location matters, history matters, and paperwork matters. Make sure the block\u2019s reputation is clean. That means checking common mail blocklists and asking about prior use. I once saw a company inherit carbon\u2011dated blacklisting baggage because the block had been part of an old botnet range. They spent weeks untangling it. Pay the small premium for clean, or budget time for cleanup\u2014it\u2019s one or the other.<\/p>\n<p>Validate the route story. Ask about ROAs and RPKI status in plain language: can this be announced cleanly without you getting caught in someone else\u2019s leak? Confirm the authorization path\u2014LOA or whatever your provider requires\u2014and that the chain of custody is clear. Watch out for gotchas like mismatched WHOIS or stale geolocation. That last one sounds minor until your Turkish users get mapped to Toronto for a month and your ads go sideways.<\/p>\n<p>If you\u2019re operating in North America, give <a href=\"https:\/\/www.arin.net\/resources\/transfer\/\" rel=\"nofollow noopener\" target=\"_blank\">ARIN\u2019s transfer process overview<\/a> a skim before you talk to a broker. It helps set expectations on documents and timelines. The same logic applies in other regions: read the basics once, skip a week of email back\u2011and\u2011forth later.<\/p>\n<p>Should you lease or buy? It depends on how durable your need is. If this is a short\u2011term spike or an experiment, leasing can be perfect. If you know you\u2019ll need the addresses for years, buying gives you control and sometimes lowers your long\u2011run cost, though you\u2019ll carry the responsibility for management, announcements, and reputation. If a cloud provider supports BYOIP, bringing your block can simplify consistency across regions and platforms, but don\u2019t gloss over the operational chores. Ownership feels great until you have to respond to an abuse ticket on a Sunday morning.<\/p>\n<h2 id='section-6'><span id=\"The_IPv6_path_that_actually_sticks\">The IPv6 path that actually sticks<\/span><\/h2>\n<p>Let me share a small win. A client wanted to shave IPv4 costs but was nervous about breaking users. We enabled dual\u2011stack on the edge, created AAAA records, and tested the rollout behind a feature flag. No fireworks. Traffic steadily shifted to IPv6 where available, which lowered connection counts on the IPv4 side and made capacity planning saner. The biggest surprise for the team wasn\u2019t performance; it was how quiet the change felt when done carefully.<\/p>\n<p>The beauty of dual\u2011stack is that it\u2019s almost invisible to users when you do it right. Modern systems use a technique often called Happy Eyeballs to prefer the fastest path without punishing slower setups. You give clients a choice, and they take the better route. On the server side, enabling IPv6 on web and API layers is usually straightforward. Certificates cover both, your app barely notices, and you get to stop paying for every new IPv4 you thought you needed.<\/p>\n<p>Content delivery helps too. Many CDNs terminate on IPv6 and backhaul to your origin however you prefer. If you\u2019ve been hesitating, read a gentle primer like <a href=\"https:\/\/www.cloudflare.com\/learning\/ipv6\/what-is-ipv6\/\" rel=\"nofollow noopener\" target=\"_blank\">Cloudflare\u2019s plain\u2011English primer on IPv6<\/a> and then flip it on in one low\u2011risk environment. Watch your graphs. If you\u2019ve got a global audience, you\u2019ll see more IPv6 traffic than you expect, especially on mobile networks.<\/p>\n<p>Now the honest part: email is still the cave. Plenty of receiving systems accept IPv6, but the culture around reputation and filtering remains rooted in IPv4. My rule of thumb is dual\u2011stack where possible, but always keep an IPv4 path for mail until your partners, providers, and metrics say otherwise. For web, APIs, and user traffic, though, IPv6 is the present\u2014not just the future.<\/p>\n<h2 id='section-7'><span id=\"Operational_hygiene_that_saves_real_money\">Operational hygiene that saves real money<\/span><\/h2>\n<p>I once inherited a fleet with a noble but expensive policy: \u201cGive everything a public IP because it\u2019s easier to reach for support.\u201d What it really did was make firewall rules a mess and the invoice bloated. We put a jump host in place, tightened up bastion access, and turned off most of those public addresses. The support team didn\u2019t miss a step, and we shaved a line item that looked small until you multiplied it by dozens of machines.<\/p>\n<p>DNS is another quiet lever. When you renumber, set short TTLs ahead of the move, do a tidy cutover, and then restore longer TTLs. For mail, always update PTRs in lockstep with A records; mismatched reverse is the quickest way to upset spam filters. Geolocation updates matter more than people think, especially if you serve content or payments that behave differently by region. It\u2019s a small ticket to open, a big headache to avoid.<\/p>\n<p>Keep an eye on abuse queues. Sometimes one compromised service can poison an IP\u2019s reputation faster than you\u2019d believe. Rate limiting, sane outbound policies, and alerting on odd traffic patterns are your friends. The cost of keeping a clean house is always lower than the cost of cleaning up after a mess, especially when IPv4 is precious.<\/p>\n<h2 id='section-8'><span id=\"What_Id_do_if_I_were_starting_today\">What I\u2019d do if I were starting today<\/span><\/h2>\n<p>I\u2019d begin with a tiny, high\u2011quality pool of IPv4s and a clear plan for where they live: edge entry points, mail, and a few special\u2011purpose cases that truly need them. Everything else goes private with egress NAT. I\u2019d turn on IPv6 on day one, not because it\u2019s trendy, but because it reduces pressure on the IPv4 side and future\u2011proofs the surface I\u2019ll have to touch in a year.<\/p>\n<p>For sending mail, I\u2019d isolate transactional and marketing traffic and warm addresses slowly. I\u2019d keep my reverse DNS squeaky clean and automate as much as I can so mistakes don\u2019t sneak in at 2 a.m. On the web front, I\u2019d consolidate domains onto shared front doors with SNI, and keep my certificates organized without over\u2011allocating IPs. I\u2019d monitor blocklists as a routine, not a crisis drill, so surprises stay small.<\/p>\n<p>When it\u2019s time to expand, I\u2019d evaluate leasing first if the need is short\u2011lived, and buying only when I\u2019m sure. Before any transaction, I\u2019d verify the routeability, the paperwork, and the history. And I\u2019d write down the runbook for renumbering and cutovers so the team isn\u2019t guessing under pressure next time.<\/p>\n<h2 id='section-9'><span id=\"A_few_things_that_feel_counterintuitive_but_work\">A few things that feel counterintuitive (but work)<\/span><\/h2>\n<p>Sharing works better than you think. The instinct to dedicate a public IPv4 to every domain or microservice is strong, but it\u2019s rarely necessary. SNI lets you collapse many front doors into one. A single, well\u2011designed load balancer pair can do the work of a dozen small edge points. And when you do need to spread across regions, bring discipline, not sprawl: repeat the pattern cleanly rather than improvising another handful of IPs \u201cjust for now.\u201d We both know \u201cjust for now\u201d becomes forever.<\/p>\n<p>NAT isn\u2019t the villain. The bad old days of ugly logs and finger\u2011pointing are fading. With flow logs, connection tagging, and modern observability, NATed fleets can be easier to reason about than a sea of public IPs. The egress points become security and compliance checkpoints, which simplifies audits too.<\/p>\n<p>IPv6 adoption isn\u2019t an all\u2011or\u2011nothing move. It\u2019s perfectly fine to enable dual\u2011stack on the edge, watch traffic shift, and take the wins as they come. Your team will gain confidence, your metrics will show the real picture, and you\u2019ll be spending less time hunting for extra IPv4s that you didn\u2019t really need.<\/p>\n<h2 id='section-10'><span id=\"The_money_conversation_youll_actually_have_with_your_team\">The money conversation you\u2019ll actually have with your team<\/span><\/h2>\n<p>At some point, someone will ask, \u201cCan we cut this IPv4 line item in half?\u201d The honest answer is often yes, but it\u2019ll come from design, not haggling. Start with a map: which services truly require a public IP, and which can move behind the edge? How many mail streams deserve isolation? Which environments still carry legacy allocations they don\u2019t use? When you convert those answers into architecture changes, the savings show up in the next billing cycle\u2014without sacrificing reliability.<\/p>\n<p>The flip side is recognizing places where spending is justified. If your business depends on email landing in inboxes, a clean, dedicated IPv4 is cheap compared to lost revenue from poor deliverability. If your security posture benefits from purposeful separation, that\u2019s money well spent. The trick is to be intentional, not casual, with every address you hold.<\/p>\n<h2 id='section-11'><span id=\"One_last_resource_trio_if_you_want_to_go_deeper\">One last resource trio if you want to go deeper<\/span><\/h2>\n<p>For background on how we got here, I still point folks to <a href=\"https:\/\/www.iana.org\/assignments\/ipv4-address-space\/ipv4-address-space.xhtml\" rel=\"nofollow noopener\" target=\"_blank\">IANA\u2019s note on the final IPv4 allocations<\/a>. If you\u2019re eyeing the transfer market in North America, <a href=\"https:\/\/www.arin.net\/resources\/transfer\/\" rel=\"nofollow noopener\" target=\"_blank\">ARIN\u2019s transfer process overview<\/a> is worth a look before you email brokers. And if you want a friendly explainer your teammates won\u2019t dread, <a href=\"https:\/\/www.cloudflare.com\/learning\/ipv6\/what-is-ipv6\/\" rel=\"nofollow noopener\" target=\"_blank\">Cloudflare\u2019s plain\u2011English primer on IPv6<\/a> is a great nudge to finally flip the switch.<\/p>\n<h2 id='section-12'><span id=\"Wrapup_the_calm_path_through_IPv4_Exhaustion_and_Price_Surges\">Wrap\u2011up: the calm path through IPv4 Exhaustion and Price Surges<\/span><\/h2>\n<p>When that invoice line first stings, it\u2019s tempting to blame the market and move on. But there\u2019s a calmer path. Start by shrinking your public surface: put services behind smart edges, share IPv4s aggressively with SNI, and centralize egress. Protect the IPs that matter, especially for mail, and keep their reputation pristine. When you need more addresses, treat the market like real estate\u2014check the neighborhood, the paperwork, and the history before you sign.<\/p>\n<p>Then give yourself breathing room by turning on IPv6 where it makes sense. Dual\u2011stack is not a personality test; it\u2019s a practical way to reduce pressure on your IPv4 pool and future\u2011proof your stack. With a few careful steps, the price conversation becomes easier, the architecture gets cleaner, and those \u201ctemporary\u201d exceptions stop piling up.<\/p>\n<p>Hope this was helpful. If this sparked ideas or you want to swap stories about reclaiming runaway IP allocations without breaking production, I\u2019m all ears. See you in the next post\u2014and may your PTRs always match your A records.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>It started with a tiny line on a client\u2019s invoice. Not the CPU, not the storage, not even the bandwidth. A few bucks tagged onto every server for \u201cIPv4 rental.\u201d At first it felt harmless\u2014coffee money. Then a couple more apps came online, one more region spun up, a staging environment for a big launch, [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":1828,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[32,33,30,25],"tags":[],"class_list":["post-1827","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-alan-adi","category-nasil-yapilir","category-nedir","category-sunucu"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/1827","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=1827"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/1827\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/1828"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=1827"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=1827"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=1827"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}