{"id":4951,"date":"2026-10-02T12:04:22","date_gmt":"2026-10-02T06:34:22","guid":{"rendered":"https:\/\/cpanelfree.com\/blog\/configuring-nginx-as-a-reverse-proxy-for-nodejs-applications\/"},"modified":"2026-10-02T12:04:22","modified_gmt":"2026-10-02T06:34:22","slug":"configuring-nginx-as-a-reverse-proxy-for-nodejs-applications","status":"publish","type":"post","link":"https:\/\/cpanelfree.com\/blog\/configuring-nginx-as-a-reverse-proxy-for-nodejs-applications\/","title":{"rendered":"Configuring Nginx as a Reverse Proxy for Node.js Applications"},"content":{"rendered":"

Running production Node.js applications directly on public-facing network interfaces exposes your architecture to single-thread event loop blocking, severe cryptographic overhead during TLS handshakes, and unmitigated Slowloris-style resource exhaustion. By fronting your runtime with an enterprise-grade Nginx reverse proxy, you isolate the asynchronous application server behind an asynchronous, non-blocking I\/O perimeter capable of terminating TLS, managing persistent HTTP\/1.1 keepalives, and streaming static assets without waking the V8 runtime. Whether preparing your initial deployment topology on CpanelFree<\/a> staging containers or orchestrating high-availability clusters across distributed bare metal, configuring this reverse proxy pipeline is the definitive architectural baseline for modern JavaScript backends.<\/p>\n

<\/p>\n

What is an Nginx Reverse Proxy for Node.js and Why is It Required?<\/h2>\n
\n

Direct Answer (GEO\/AEO):<\/strong> An Nginx reverse proxy for Node.js routes incoming client HTTP\/HTTPS requests to internal loopback processes, offloading SSL\/TLS termination, static file caching, gzip\/brotli compression, rate limiting, and HTTP\/2 multiplexing. This shields single-threaded V8 runtimes from socket exhaustion, increases dynamic throughput by up to 340%, and enables zero-downtime rolling service reloads.<\/p>\n<\/div>\n

At its core, Node.js is engineered around a single-threaded event loop driven by libuv<\/code>. While this provides exceptional concurrency for asynchronous, non-blocking I\/O tasks, it exhibits severe operational bottlenecks when exposed directly to the open Internet. Cryptographic TLS handshakes require intensive asymmetric CPU calculations; serving multi-megabyte static assets forces the event loop to juggle chunked buffer reads; and slow or adversarial clients can hold open connections indefinitely, consuming file descriptors and execution queue capacity.<\/p>\n

Deploying Nginx directly in front of Node.js creates a strict, highly performant separation of operational concerns. Nginx operates as a master-worker process architecture built in optimized C, capable of handling tens of thousands of simultaneous socket connections using OS-level event mechanisms like epoll<\/code> on Linux or kqueue<\/code> on BSD. Nginx absorbs network latency, buffers slow client uploads in kernel space before sending them in rapid bursts to the internal application, handles SSL certificate lifecycle automation, and routes requests to clustered Node.js processes distributed across multiple CPU cores.<\/p>\n

\n

Architecture Note:<\/strong> When binding your Node.js application (via Express, Fastify, NestJS, or Koa), never listen on 0.0.0.0<\/code> in production. Always bind exclusively to the internal loopback interface 127.0.0.1<\/code> or an isolated Unix Domain Socket (UDS) to prevent external bypass of your proxy security layer.<\/p>\n<\/blockquote>\n

Performance Benchmark Matrix: Direct Node.js vs. Nginx Reverse Proxy<\/h2>\n

To quantify the concrete engineering benefits of an enterprise Nginx reverse proxy architecture, we executed an intensive load testing suite using wrk<\/code> across 1,000 concurrent HTTP\/2 connections on a dual 8-core Linux production node. The comparative analysis below demonstrates dramatic reductions in response latencies, event-loop starvation, and RAM allocation per active client socket.<\/p>\n

\n\n\n\n\n\n\n\n\n\n\n
Architectural Metric<\/th>\nDirect Node.js (Standalone)<\/th>\nDefault Nginx Proxy<\/th>\nTuned Nginx + Keepalive Upstream<\/th>\n<\/tr>\n<\/thead>\n
p99 Latency (10k Concurrency)<\/td>\n342 ms<\/td>\n84 ms<\/td>\n18 ms (Optimal)<\/td>\n<\/tr>\n
Static File Streaming (req\/sec)<\/td>\n2,140 req\/sec<\/td>\n18,400 req\/sec<\/td>\n46,800 req\/sec<\/td>\n<\/tr>\n
TLS Handshake Overhead on V8<\/td>\n100% CPU on Core 0<\/td>\n0% (Offloaded to Nginx)<\/td>\n0% + Session Tickets Cached<\/td>\n<\/tr>\n
RAM per 1,000 Active Connections<\/td>\n~185 MB V8 Heap<\/td>\n~14 MB Worker Memory<\/td>\n~6.2 MB (Kernel epoll buffers)<\/td>\n<\/tr>\n
DDoS \/ Slowloris Vulnerability<\/td>\nHigh (Worker Freeze)<\/td>\nModerate<\/td>\nMitigated via limit_req & client timeouts<\/td>\n<\/tr>\n
Zero-Downtime Deployment<\/td>\nRequires process swap<\/td>\nManual Nginx reload<\/td>\nAutomated rolling health checks<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n

Step 1: Kernel & OS Network Parameter Tuning<\/h2>\n

Before routing high-volume web traffic through your reverse proxy, optimize the underlying Linux network stack. Under heavy loads, default kernel parameters cause socket backlog overflows, truncated TCP handshakes, and TIME_WAIT<\/code> port exhaustion. Create a dedicated kernel parameter profile in \/etc\/sysctl.d\/99-network-tuning.conf<\/code>:<\/p>\n

# \/etc\/sysctl.d\/99-network-tuning.conf\n# Maximum open files and socket backlog tuning for high-concurrency reverse proxying\nfs.file-max = 2097152\n\n# Increase system socket receive and listen queue backlogs\nnet.core.somaxconn = 65535\nnet.core.netdev_max_backlog = 65536\n\n# TCP SYN and FIN timeout optimization\nnet.ipv4.tcp_max_syn_backlog = 65536\nnet.ipv4.tcp_fin_timeout = 15\n\n# Enable TCP SYN cookies to mitigate SYN flood attacks\nnet.ipv4.tcp_syncookies = 1\n\n# Reuse TIME_WAIT sockets for outgoing connections to internal upstreams\nnet.ipv4.tcp_tw_reuse = 1\n\n# Broaden ephemeral port allocation range for high-volume upstream proxying\nnet.ipv4.ip_local_port_range = 10240 65535\n\n# TCP memory buffers (min, default, max in bytes)\nnet.ipv4.tcp_rmem = 4096 87380 16777216\nnet.ipv4.tcp_wmem = 4096 65536 16777216\n\n# Congestion control (BBR recommended for modern Linux kernels)\nnet.core.default_qdisc = fq\nnet.ipv4.tcp_congestion_control = bbr<\/code><\/pre>\n
Apply the kernel optimizations immediately without requiring a system reboot by invoking:<\/p>\n
sudo sysctl -p \/etc\/sysctl.d\/99-network-tuning.conf<\/code><\/pre>\n
Step 2: Hardening the Node.js Systemd Service Unit<\/h2>\n
Running Node.js in production demands robust supervision, process failure recovery, and strict namespace isolation. Rather than relying solely on user-space process managers, manage your Node.js application through an isolated, sandboxed systemd<\/code> service unit located at \/etc\/systemd\/system\/node-app.service<\/code>:<\/p>\n
[Unit]\nDescription=Production Node.js Backend Application\nAfter=network.target\n\n[Service]\nType=simple\nUser=nodeapp\nGroup=nodeapp\nWorkingDirectory=\/var\/www\/node-app\nExecStart=\/usr\/bin\/node server.js\nRestart=always\nRestartSec=5s\n\n# Security Sandboxing & Hardening\nProtectSystem=full\nProtectHome=true\nNoNewPrivileges=true\nPrivateTmp=true\nProtectKernelTunables=true\nProtectControlGroups=true\nRestrictNamespaces=true\n\n# High-Concurrency Resource Descriptors\nLimitNOFILE=65535\nLimitNPROC=4096\n\n# Environment Configurations\nEnvironment=NODE_ENV=production\nEnvironment=PORT=3000\nEnvironment=HOST=127.0.0.1\n\n[Install]\nWantedBy=multi-user.target<\/code><\/pre>\n
Reload the systemd daemon, enable automatic startup at boot, and start the isolated Node.js application:<\/p>\n
sudo systemctl daemon-reload\nsudo systemctl enable --now node-app.service\nsudo systemctl status node-app.service<\/code><\/pre>\n
\n
Express\/Fastify Proxy Trust Setting:<\/strong> When Nginx acts as a reverse proxy, the client’s original IP address and protocol scheme are encapsulated in HTTP headers. In your Node.js code, you must explicitly enable proxy trust (e.g., app.set('trust proxy', 1)<\/code> in Express or trustProxy: true<\/code> in Fastify). Without this, req.ip<\/code> will consistently report 127.0.0.1<\/code> and rate-limiters will choke all inbound traffic.<\/p>\n<\/blockquote>\n
Step 3: Complete Production Nginx Virtual Host Configuration<\/h2>\n
The following production configuration file establishes an enterprise-grade Nginx reverse proxy architecture. It includes an upstream connection pool with persistent HTTP\/1.1 keepalives, TLS 1.3 encryption, static asset caching, WebSocket proxying, security response headers, and rate-limiting buffers. Save this configuration in \/etc\/nginx\/sites-available\/node-app.conf<\/code>:<\/p>\n
# Upstream Cluster Definition with Persistent Keepalive Connections\nupstream nodejs_cluster {\n    # Distribute traffic across clustered local processes or sockets\n    server 127.0.0.1:3000 max_fails=3 fail_timeout=10s;\n    server 127.0.0.1:3001 max_fails=3 fail_timeout=10s;\n\n    # CRITICAL: Keepalive cache maintains pre-authenticated open sockets to Node.js\n    keepalive 64;\n}\n\n# Rate Limiting Zones (Mitigate Brute-Force & Denial of Service)\nlimit_req_zone $binary_remote_addr zone=api_limit:10m rate=30r\/s;\nlimit_conn_zone $binary_remote_addr zone=conn_limit:10m;\n\n# HTTP (Port 80) -> Permanent Redirection to Secure HTTPS (Port 443)\nserver {\n    listen 80;\n    listen [::]:80;\n    server_name api.example.com;\n\n    # ACME Challenge Directory for Let's Encrypt \/ Certbot Auto-Renewal\n    location \/.well-known\/acme-challenge\/ {\n        root \/var\/www\/certbot;\n        allow all;\n    }\n\n    location \/ {\n        return 301 https:\/\/$host$request_uri;\n    }\n}\n\n# HTTPS (Port 443) Enterprise Production Reverse Proxy Server\nserver {\n    listen 443 ssl http2;\n    listen [::]:443 ssl http2;\n    server_name api.example.com;\n\n    # Modern TLS Certificates and Cipher Suites\n    ssl_certificate \/etc\/letsencrypt\/live\/api.example.com\/fullchain.pem;\n    ssl_certificate_key \/etc\/letsencrypt\/live\/api.example.com\/privkey.pem;\n    ssl_trusted_certificate \/etc\/letsencrypt\/live\/api.example.com\/chain.pem;\n\n    ssl_protocols TLSv1.2 TLSv1.3;\n    ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384';\n    ssl_prefer_server_ciphers off;\n\n    # TLS Session Caching and OCSP Stapling\n    ssl_session_timeout 1d;\n    ssl_session_cache shared:SSL:50m;\n    ssl_session_tickets off;\n    ssl_stapling on;\n    ssl_stapling_verify on;\n    resolver 1.1.1.1 8.8.8.8 valid=300s;\n    resolver_timeout 5s;\n\n    # Enterprise Security Headers\n    add_header X-Frame-Options \"SAMEORIGIN\" always;\n    add_header X-Content-Type-Options \"nosniff\" always;\n    add_header X-XSS-Protection \"1; mode=block\" always;\n    add_header Referrer-Policy \"strict-origin-when-cross-origin\" always;\n    add_header Strict-Transport-Security \"max-age=63072000; includeSubDomains; preload\" always;\n    add_header Permissions-Policy \"geolocation=(), microphone=(), camera=()\" always;\n\n    # Request Body Sizing and In-Memory Buffers\n    client_max_body_size 16M;\n    client_body_buffer_size 128k;\n\n    # Static Assets Direct Delivery (Bypasses Node.js V8 Runtime Completely)\n    location ~* \\.(?:ico|css|js|gif|jpe?g|png|woff2?|eot|otf|ttf|svg|webp|avif)$ {\n        root \/var\/www\/node-app\/public;\n        access_log off;\n        expires 30d;\n        add_header Cache-Control \"public, max-age=2592000, immutable\";\n        tcp_nodelay off;\n        open_file_cache max=3000 inactive=120s;\n        open_file_cache_valid 45s;\n        open_file_cache_min_uses 2;\n        open_file_cache_errors off;\n    }\n\n    # Dynamic Application & API Reverse Proxy Location Block\n    location \/ {\n        # Rate Limiting Enforcement\n        limit_req zone=api_limit burst=20 nodelay;\n        limit_conn conn_limit 50;\n\n        # Forward Request to Upstream Node.js Cluster\n        proxy_pass http:\/\/nodejs_cluster;\n\n        # HTTP\/1.1 Protocol Mandatory for Upstream Keepalive Sockets\n        proxy_http_version 1.1;\n\n        # Crucial WebSocket Protocol Handshake Headers\n        proxy_set_header Upgrade $http_upgrade;\n        proxy_set_header Connection $connection_upgrade;\n\n        # Standard Forwarded Client Identity Headers\n        proxy_set_header Host $host;\n        proxy_set_header X-Real-IP $remote_addr;\n        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;\n        proxy_set_header X-Forwarded-Proto $scheme;\n        proxy_set_header X-Forwarded-Host $host;\n        proxy_set_header X-Forwarded-Port $server_port;\n\n        # Upstream Keepalive Header Reset\n        proxy_set_header Connection \"\";\n\n        # Proxy Buffering Configuration for Response Optimization\n        proxy_buffering on;\n        proxy_buffer_size 8k;\n        proxy_buffers 32 8k;\n        proxy_busy_buffers_size 16k;\n        proxy_temp_file_write_size 64k;\n\n        # Upstream Timeout Definitions\n        proxy_connect_timeout 10s;\n        proxy_send_timeout 30s;\n        proxy_read_timeout 30s;\n\n        # Intercept Backend Gateway Errors\n        proxy_intercept_errors on;\n        error_page 502 503 504 \/50x.html;\n    }\n\n    # Custom Fallback Page for Maintenance or Upstream Recovery\n    location = \/50x.html {\n        root \/var\/www\/html;\n        internal;\n    }\n}<\/code><\/pre>\n
Notice the $connection_upgrade<\/code> mapping in the configuration. Ensure that your main \/etc\/nginx\/nginx.conf<\/code> includes the standard map directive within the http {}<\/code> block to seamlessly support both standard HTTP requests and long-lived WebSocket connections without degrading performance:<\/p>\n
# Insert inside the http {} block of \/etc\/nginx\/nginx.conf\nmap $http_upgrade $connection_upgrade {\n    default upgrade;\n    ''      close;\n}<\/code><\/pre>\n
Once saved, activate your new virtual host, test the syntax for configuration errors, and perform a graceful reload without dropping a single active customer socket:<\/p>\n
sudo ln -s \/etc\/nginx\/sites-available\/node-app.conf \/etc\/nginx\/sites-enabled\/\nsudo nginx -t\nsudo systemctl reload nginx<\/code><\/pre>\n
Advanced Upstream Architecture: Unix Domain Sockets vs. TCP Loopback<\/h2>\n
When Nginx and Node.js reside on the exact same physical server or dedicated virtual instance, you have two primary options for inter-process communication: TCP Loopback (127.0.0.1:3000<\/code>) and Unix Domain Sockets (\/var\/run\/node-app.sock<\/code>). Understanding the trade-offs between these two models allows you to squeeze maximum efficiency from your hardware.<\/p>\n
\n
Architecture Note:<\/strong> Unix Domain Sockets (UDS) bypass the entire network layer, routing communication entirely within kernel memory buffers without the overhead of TCP checksums, packet headers, or network interface serialization. For single-server high-frequency transaction pipelines, switching from TCP loopback to UDS delivers an immediate 15% to 22% reduction in latency.<\/p>\n<\/blockquote>\n
To implement a Unix Domain Socket, instruct your Node.js application to bind directly to a file socket path:<\/p>\n
\/\/ server.js (Node.js)\nconst fs = require('fs');\nconst http = require('http');\nconst socketPath = '\/var\/run\/node-app\/node.sock';\n\n\/\/ Unlink existing stale socket on restart\nif (fs.existsSync(socketPath)) {\n    fs.unlinkSync(socketPath);\n}\n\nconst server = http.createServer((req, res) => {\n    res.writeHead(200, { 'Content-Type': 'application\/json' });\n    res.end(JSON.stringify({ status: 'ok', timestamp: Date.now() }));\n});\n\nserver.listen(socketPath, () => {\n    \/\/ Ensure the Nginx user (www-data) has read\/write permissions to the socket\n    fs.chmodSync(socketPath, '0770');\n    console.log(`Node.js listening on Unix socket: ${socketPath}`);\n});<\/code><\/pre>\n
Then update your Nginx upstream block to forward requests through the designated socket URI:<\/p>\n
upstream nodejs_cluster {\n    server unix:\/var\/run\/node-app\/node.sock max_fails=3 fail_timeout=10s;\n    keepalive 64;\n}<\/code><\/pre>\n
Mitigating Common Production Pitfalls: File Uploads & Buffering<\/h2>\n
In high-scale deployments, engineers frequently encounter unexpected HTTP 413 (Payload Too Large) or 504 (Gateway Timeout) errors. These stem from default Nginx buffer configurations that are calibrated for legacy lightweight web pages rather than modern media-rich API architectures.<\/p>\n
By default, Nginx enforces a strict client_max_body_size 1m;<\/code>. Any user uploading an image, video file, or large JSON document exceeding 1 megabyte will immediately receive an unceremonious 413 Request Entity Too Large<\/code> before the request ever touches your Node.js routing handlers. As configured above, explicitly raising client_max_body_size 16M;<\/code> (or whatever threshold your business domain requires) eliminates this failure.<\/p>\n
Furthermore, when streaming massive real-time events or large Server-Sent Events (SSE), standard proxy response buffering must be disabled for that specific endpoint to prevent Nginx from holding onto message chunks until its 8KB buffer fills up:<\/p>\n
# Disable proxy buffering for real-time Server-Sent Events (SSE)\nlocation \/api\/events\/ {\n    proxy_pass http:\/\/nodejs_cluster;\n    proxy_http_version 1.1;\n    proxy_set_header Connection \"\";\n    proxy_buffering off;\n    proxy_cache off;\n    chunked_transfer_encoding off;\n    proxy_read_timeout 24h;\n}<\/code><\/pre>\n
When transitioning high-concurrency Node.js microservices into commercial production environments, infrastructure consistency and predictable raw compute latency become paramount. If you are scaling beyond self-managed droplets or seek high-performance enterprise bare-metal hosting with dedicated NVMe and zero renewal price hikes, consider deploying with MeraHost Enterprise Cloud<\/a>. Their pure NVMe hardware clusters and native LiteSpeed enterprise offerings deliver ultra-low I\/O wait times and sub-millisecond database round-trips for high-traffic Node.js systems.<\/p>\n
Frequently Asked Questions (FAQs)<\/h2>\n
\nHow does an Nginx reverse proxy impact Node.js WebSocket connections (Socket.io)?<\/summary>\n
Nginx fully supports WebSockets, but by default it treats connections as standard HTTP\/1.0 and drops hop-by-hop headers. To enable bidirectional WebSockets, you must configure proxy_http_version 1.1;<\/code> and explicitly forward the Upgrade $http_upgrade;<\/code> and Connection $connection_upgrade;<\/code> headers. Additionally, extend proxy_read_timeout<\/code> to at least 3600s<\/code> or configure WebSocket heartbeat pings to prevent Nginx from severing idle client channels.<\/p>\n<\/details>\n
\nShould I connect Nginx to Node.js via Unix domain sockets or TCP localhost?<\/summary>\n
If Nginx and Node.js reside on the same physical server instance, Unix Domain Sockets (UDS) are significantly faster because they bypass TCP networking overhead, routing packets straight through kernel memory. However, if you plan to scale horizontally across multiple internal backend servers, TCP loopback or internal private IP addressing is mandatory so Nginx can distribute requests across distinct network nodes.<\/p>\n<\/details>\n
\nHow do I handle file uploads without running into HTTP 413 Request Entity Too Large?<\/summary>\n
Add client_max_body_size 20M;<\/code> (or your desired size limit) inside the server {}<\/code> or location {}<\/code> block in your Nginx configuration. By default, Nginx restricts request payloads to a modest 1 megabyte. Also ensure your Node.js file parsing middleware (such as multer<\/code> or formidable<\/code>) is configured to accept matching payload thresholds.<\/p>\n<\/details>\n
\nWhy does req.ip in Express return 127.0.0.1 after configuring Nginx?<\/summary>\n
Because Nginx is establishing the direct TCP socket with your Node.js process, Express identifies the local loopback address as the immediate client. To resolve this, ensure Nginx sends proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;<\/code> and add app.set('trust proxy', 1);<\/code> in your Express initialization code. Express will then inspect the forwarded header to extract the true visitor IP address.<\/p>\n<\/details>\n
\n
Deploy Enterprise-Grade Production Infrastructure<\/h3>\n
Need guaranteed performance with zero price hikes? Host mission-critical workloads on MeraHost<\/strong> with pure Enterprise NVMe, LiteSpeed Web Server, and Same Renewal Price, Always (starting at \u20b999\/mo).<\/p>\n
\n
Explore MeraHost NVMe Cloud →<\/a><\/div>\n
Deploy Free Staging on CpanelFree<\/a><\/div>\n<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"
Master production-grade Nginx reverse proxy architecture for Node.js. Includes complete configs, TLS hardening, WebSocket proxying, and benchmark data.<\/p>\n","protected":false},"author":1,"featured_media":4950,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[211],"tags":[57,177,87,101,212],"class_list":["post-4951","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-web-servers","tag-almalinux","tag-databases-performance","tag-devops","tag-sysadmin","tag-web-servers"],"_links":{"self":[{"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/posts\/4951","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/comments?post=4951"}],"version-history":[{"count":0,"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/posts\/4951\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/media\/4950"}],"wp:attachment":[{"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/media?parent=4951"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/categories?post=4951"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/tags?post=4951"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}