{"id":1315,"date":"2026-02-22T16:00:00","date_gmt":"2026-02-22T15:00:00","guid":{"rendered":"https:\/\/darioiannascoli.it\/blog\/reverse-proxy-nginx-piu-siti-server\/"},"modified":"2026-02-22T16:00:00","modified_gmt":"2026-02-22T15:00:00","slug":"reverse-proxy-nginx-piu-siti-server","status":"publish","type":"post","link":"https:\/\/darioiannascoli.it\/blog\/reverse-proxy-nginx-piu-siti-server\/","title":{"rendered":"Come Configuro un Reverse Proxy Nginx per Gestire Pi\u00f9 Siti su un Solo Server: Guida Pratica"},"content":{"rendered":"<p>Se gestite pi\u00f9 siti web o applicazioni su un singolo server, prima o poi vi troverete a dover affrontare un problema fondamentale: come instradare correttamente il traffico in ingresso verso il backend giusto? Nella mia esperienza di system administrator, la risposta \u00e8 quasi sempre la stessa: configurare <strong>Nginx come reverse proxy<\/strong>.<\/p>\n<p>Nel corso degli anni ho configurato decine di server con pi\u00f9 domini serviti dallo stesso indirizzo IP, e il <em>reverse proxy<\/em> Nginx si \u00e8 sempre dimostrato la soluzione pi\u00f9 affidabile, performante e scalabile. In questa guida vi mostro esattamente come faccio, partendo dall&#8217;installazione fino alla messa in sicurezza completa, con configurazioni reali che uso quotidianamente.<\/p>\n<p>Se avete gi\u00e0 letto il mio articolo su <a href=\"https:\/\/darioiannascoli.it\/blog\/compressione-brotli-nginx-performance-server\/\">come abilito la compressione Brotli su Nginx<\/a>, sapete che considero Nginx uno strumento essenziale nel mio toolkit. Oggi approfondiamo un aspetto ancora pi\u00f9 critico: il <strong>reverse proxy per pi\u00f9 siti<\/strong>.<\/p>\n<h2>Cos&#8217;\u00e8 un Reverse Proxy Nginx e Perch\u00e9 Usarlo<\/h2>\n<p>Un <em>reverse proxy<\/em> \u00e8 un server che si interpone tra i client e i backend, ricevendo le richieste in ingresso e inoltrandole al servizio appropriato. A differenza di un <em>forward proxy<\/em>, che nasconde i client ai server, il reverse proxy nasconde l&#8217;infrastruttura interna ai visitatori.<\/p>\n<p>Nginx \u00e8 la scelta pi\u00f9 popolare per i deployment come reverse proxy grazie alla sua architettura <em>event-driven<\/em>, al basso consumo di memoria e alla capacit\u00e0 di gestire migliaia di connessioni simultanee in modo efficiente. Un singolo worker process di Nginx pu\u00f2 gestire migliaia di connessioni concorrenti con un overhead minimo di risorse.<\/p>\n<p>I vantaggi principali che ottengo utilizzando Nginx come reverse proxy sono:<\/p>\n<ul>\n<li><strong>Load balancing<\/strong> \u2014 distribuire le richieste su pi\u00f9 backend<\/li>\n<li><strong>SSL termination<\/strong> \u2014 gestire la crittografia TLS in un unico punto<\/li>\n<li><strong>Caching<\/strong> \u2014 servire risposte ripetute senza colpire il backend<\/li>\n<li><strong>Sicurezza<\/strong> \u2014 nascondere l&#8217;infrastruttura interna e filtrare richieste malevole<\/li>\n<li><strong>Compressione<\/strong> \u2014 ridurre la banda con gzip\/Brotli prima dell&#8217;invio al client<\/li>\n<\/ul>\n<h2>Prerequisiti e Installazione di Nginx<\/h2>\n<p>Prima di partire, assicuratevi di avere:<\/p>\n<ul>\n<li>Un server Linux (Ubuntu 22.04\/24.04 o Debian 12) con accesso root<\/li>\n<li>Almeno due domini o sottodomini puntati all&#8217;IP del server<\/li>\n<li>Le applicazioni o i siti gi\u00e0 in esecuzione su porte interne diverse<\/li>\n<\/ul>\n<h3>Installazione di Nginx su Ubuntu\/Debian<\/h3>\n<p>Aggiorno i pacchetti e installo Nginx:<\/p>\n<pre><code>sudo apt update &amp;&amp; sudo apt upgrade -y\nsudo apt install nginx -y<\/code><\/pre>\n<p>Verifico che il servizio sia attivo:<\/p>\n<pre><code>sudo systemctl status nginx\nsudo systemctl enable nginx<\/code><\/pre>\n<h3>Installazione su RHEL\/Rocky Linux\/AlmaLinux<\/h3>\n<p>Per le distribuzioni RHEL-based il procedimento \u00e8 leggermente diverso:<\/p>\n<pre><code>sudo dnf install epel-release -y\nsudo dnf install nginx -y\nsudo systemctl start nginx &amp;&amp; sudo systemctl enable nginx<\/code><\/pre>\n<h2>Configurare il Reverse Proxy Nginx per Pi\u00f9 Siti: Server Block<\/h2>\n<p>Il cuore della configurazione \u00e8 il concetto di <strong>server block<\/strong> (l&#8217;equivalente dei Virtual Host di Apache). Ogni server block rappresenta un sito o un&#8217;applicazione separata e definisce come Nginx gestisce le richieste in ingresso per quel dominio specifico.<\/p>\n<p>Creo un file di configurazione separato per ogni sito nella directory <code>\/etc\/nginx\/sites-available\/<\/code>:<\/p>\n<h3>Primo sito: sito1.example.com<\/h3>\n<pre><code># \/etc\/nginx\/sites-available\/sito1.example.com\nserver {\n    listen 80;\n    server_name sito1.example.com www.sito1.example.com;\n\n    location \/ {\n        proxy_pass http:\/\/127.0.0.1:3000;\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    }\n}<\/code><\/pre>\n<h3>Secondo sito: sito2.example.com<\/h3>\n<pre><code># \/etc\/nginx\/sites-available\/sito2.example.com\nserver {\n    listen 80;\n    server_name sito2.example.com www.sito2.example.com;\n\n    location \/ {\n        proxy_pass http:\/\/127.0.0.1:4000;\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    }\n}<\/code><\/pre>\n<p>La direttiva <code>proxy_pass<\/code> \u00e8 la base della configurazione del reverse proxy Nginx: dice a Nginx dove inoltrare le richieste in ingresso. Ogni sito gira su una porta differente (3000, 4000, ecc.) e Nginx instrada il traffico in base al dominio.<\/p>\n<h3>Attivazione e Test della Configurazione<\/h3>\n<p>Attivo i siti creando i symlink e testo la configurazione:<\/p>\n<pre><code># Creo i symlink\nsudo ln -s \/etc\/nginx\/sites-available\/sito1.example.com \/etc\/nginx\/sites-enabled\/\nsudo ln -s \/etc\/nginx\/sites-available\/sito2.example.com \/etc\/nginx\/sites-enabled\/\n\n# Testo la configurazione (FONDAMENTALE prima di ogni reload)\nsudo nginx -t\n\n# Se il test \u00e8 ok, ricarico senza downtime\nsudo systemctl reload nginx<\/code><\/pre>\n<p><strong>Consiglio importante:<\/strong> testate sempre la configurazione con <code>nginx -t<\/code> prima di ricaricare. All&#8217;inizio della mia carriera ho causato pi\u00f9 di un downtime dimenticando questo passaggio!<\/p>\n<h2>Gli Header Essenziali per il Reverse Proxy<\/h2>\n<p>Quando Nginx fa da reverse proxy, le applicazioni backend perdono informazioni critiche sul client originale. Per default, Nginx modifica gli header &#8220;Host&#8221; e &#8220;Connection&#8221; nelle richieste proxiate ed elimina quelli con valori vuoti.<\/p>\n<p>Ecco gli header che configuro sempre:<\/p>\n<ul>\n<li><strong>Host $host<\/strong> \u2014 passa il dominio originale richiesto dal client<\/li>\n<li><strong>X-Real-IP $remote_addr<\/strong> \u2014 l&#8217;IP reale del visitatore<\/li>\n<li><strong>X-Forwarded-For $proxy_add_x_forwarded_for<\/strong> \u2014 mantiene la catena completa di proxy attraversati<\/li>\n<li><strong>X-Forwarded-Proto $scheme<\/strong> \u2014 indica se la richiesta originale era HTTP o HTTPS<\/li>\n<li><strong>X-Forwarded-Host $host<\/strong> \u2014 il dominio originale della richiesta<\/li>\n<li><strong>X-Forwarded-Port $server_port<\/strong> \u2014 la porta della richiesta originale<\/li>\n<\/ul>\n<p>Senza questi header, il backend vedr\u00e0 tutte le richieste come provenienti da 127.0.0.1 \u2014 un problema serio per i log, la sicurezza e la corretta generazione degli URL.<\/p>\n<h2>Abilitare HTTPS con Let&#8217;s Encrypt e Certbot<\/h2>\n<p>Un reverse proxy senza HTTPS \u00e8 un rischio inaccettabile. Nella mia configurazione abilito sempre la <em>SSL termination<\/em> su Nginx, cos\u00ec i backend interni comunicano in HTTP sulla rete locale, mentre tutto il traffico esterno \u00e8 cifrato.<\/p>\n<pre><code># Installo Certbot con il plugin Nginx\nsudo apt install certbot python3-certbot-nginx -y\n\n# Genero i certificati per entrambi i siti\nsudo certbot --nginx -d sito1.example.com -d www.sito1.example.com\nsudo certbot --nginx -d sito2.example.com -d www.sito2.example.com<\/code><\/pre>\n<p>Certbot modificher\u00e0 automaticamente i server block aggiungendo le direttive SSL. Se avete bisogno di certificati wildcard, ho spiegato la procedura completa nel mio articolo su <a href=\"https:\/\/darioiannascoli.it\/blog\/plesk-lets-encrypt-wildcard-dns-01\/\">Let&#8217;s Encrypt Wildcard con validazione DNS-01<\/a>.<\/p>\n<h3>Hardening TLS: la mia configurazione<\/h3>\n<p>Dopo l&#8217;installazione del certificato, applico sempre un hardening TLS aggiuntivo. Nascondere informazioni come la versione di Nginx, PHP e del sistema operativo \u00e8 fondamentale per ridurre la superficie d&#8217;attacco:<\/p>\n<pre><code># Dentro il server block HTTPS\nserver {\n    listen 443 ssl http2;\n    server_name sito1.example.com;\n\n    ssl_certificate \/etc\/letsencrypt\/live\/sito1.example.com\/fullchain.pem;\n    ssl_certificate_key \/etc\/letsencrypt\/live\/sito1.example.com\/privkey.pem;\n\n    # Nascondo la versione di Nginx\n    server_tokens off;\n\n    # Protocolli TLS sicuri\n    ssl_protocols TLSv1.2 TLSv1.3;\n    ssl_prefer_server_ciphers on;\n    ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384;\n\n    # Session caching per performance\n    ssl_session_timeout 1d;\n    ssl_session_cache shared:SSL:10m;\n    ssl_session_tickets off;\n\n    # Security headers\n    add_header X-Content-Type-Options nosniff;\n    add_header X-Frame-Options DENY;\n    add_header X-XSS-Protection \"1; mode=block\";\n    add_header Strict-Transport-Security \"max-age=63072000; includeSubDomains; preload\";\n\n    location \/ {\n        proxy_pass http:\/\/127.0.0.1:3000;\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    }\n}<\/code><\/pre>\n<p>Se volete approfondire la sicurezza del server, vi consiglio di leggere anche come <a href=\"https:\/\/darioiannascoli.it\/blog\/configurare-fail2ban-plesk\/\">configuro Fail2Ban per bloccare gli attacchi<\/a> e come gestisco la <a href=\"https:\/\/darioiannascoli.it\/blog\/sicurezza-wordpress-brute-force\/\">protezione WordPress da attacchi brute force<\/a>.<\/p>\n<h2>Rate Limiting e Protezione DoS<\/h2>\n<p>Una delle prime cose che configuro su ogni reverse proxy \u00e8 il <em>rate limiting<\/em>, per proteggere i backend da attacchi DoS e da bot aggressivi:<\/p>\n<pre><code># Nel blocco http di nginx.conf\nhttp {\n    limit_req_zone $binary_remote_addr zone=general:10m rate=10r\/s;\n    limit_req_zone $binary_remote_addr zone=login:10m rate=1r\/s;\n\n    # ...altre configurazioni...\n}\n\n# Nel server block specifico\nserver {\n    location \/ {\n        limit_req zone=general burst=20 nodelay;\n        proxy_pass http:\/\/127.0.0.1:3000;\n    }\n\n    location \/wp-login.php {\n        limit_req zone=login burst=3 nodelay;\n        proxy_pass http:\/\/127.0.0.1:3000;\n    }\n}<\/code><\/pre>\n<p>Con questa configurazione limito a 10 richieste\/secondo per IP sull&#8217;intero sito e a 1 richiesta\/secondo sulle pagine di login \u2014 una misura semplice ma efficacissima.<\/p>\n<h2>Load Balancing con Upstream Block<\/h2>\n<p>Quando i siti crescono, spesso serve distribuire il carico su pi\u00f9 backend. Nginx brilla particolarmente nelle architetture ad alta disponibilit\u00e0 grazie ai blocchi <em>upstream<\/em>:<\/p>\n<pre><code>upstream backend_sito1 {\n    server 192.168.1.10:3000;\n    server 192.168.1.11:3000;\n    server 192.168.1.12:3000 backup;\n}\n\nserver {\n    listen 443 ssl http2;\n    server_name sito1.example.com;\n\n    location \/ {\n        proxy_pass http:\/\/backend_sito1;\n        proxy_http_version 1.1;\n        proxy_set_header Connection \"\";\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    }\n}<\/code><\/pre>\n<p><strong>Nota critica:<\/strong> quando usate <em>keepalive<\/em> con gli upstream, dovete impostare <code>proxy_http_version 1.1<\/code> e azzerare l&#8217;header Connection. HTTP\/1.0 chiude le connessioni di default, vanificando completamente il keepalive.<\/p>\n<h2>Buffering e Ottimizzazione delle Performance<\/h2>\n<p>Nginx bufferizza le risposte dai backend prima di inviarle ai client. Questo libera rapidamente i server backend mentre Nginx gestisce le connessioni lente dei client. Nella mia esperienza, un tuning corretto del buffering fa una differenza enorme:<\/p>\n<pre><code>location \/ {\n    proxy_pass http:\/\/127.0.0.1:3000;\n\n    # Buffering ottimizzato\n    proxy_buffering on;\n    proxy_buffer_size 4k;\n    proxy_buffers 8 16k;\n    proxy_busy_buffers_size 32k;\n\n    # Timeout ragionevoli\n    proxy_connect_timeout 60s;\n    proxy_send_timeout 60s;\n    proxy_read_timeout 90s;\n}<\/code><\/pre>\n<p>Per ottimizzare ulteriormente le performance, vi consiglio di combinare queste impostazioni con la <a href=\"https:\/\/darioiannascoli.it\/blog\/ottimizzare-php-fpm-opcache-plesk\/\">configurazione di PHP-FPM e OPcache<\/a> e di attivare anche <a href=\"https:\/\/darioiannascoli.it\/blog\/http3-quic-plesk-nginx\/\">HTTP\/3 QUIC<\/a> dove possibile.<\/p>\n<h2>Monitoraggio e Logging del Reverse Proxy<\/h2>\n<p>Configuro sempre log separati per ogni sito proxiato, cos\u00ec posso diagnosticare rapidamente i problemi:<\/p>\n<pre><code>server {\n    server_name sito1.example.com;\n\n    access_log \/var\/log\/nginx\/sito1.access.log;\n    error_log \/var\/log\/nginx\/sito1.error.log;\n\n    # ...resto della configurazione...\n}<\/code><\/pre>\n<p>Per un monitoraggio pi\u00f9 avanzato, nel mio articolo su <a href=\"https:\/\/darioiannascoli.it\/blog\/monitoraggio-risorse-server-plesk-grafana-prometheus\/\">Grafana e Prometheus per il monitoraggio server<\/a> spiego come creare dashboard in tempo reale che includono le metriche di Nginx.<\/p>\n<h2>Troubleshooting: Errori Comuni e Come li Risolvo<\/h2>\n<h3>Errore 502 Bad Gateway<\/h3>\n<p>\u00c8 l&#8217;errore pi\u00f9 frequente. Significa che Nginx ha ricevuto la richiesta ma il backend ha risposto in modo invalido o non ha risposto affatto. Le cause pi\u00f9 comuni nella mia esperienza:<\/p>\n<ol>\n<li>Il backend non \u00e8 in esecuzione \u2014 verifico con <code>systemctl status<\/code> o <code>docker ps<\/code><\/li>\n<li>La <code>proxy_pass<\/code> punta alla porta sbagliata<\/li>\n<li>Il backend ascolta su 127.0.0.1 ma Nginx lo cerca su 0.0.0.0 (o viceversa)<\/li>\n<li>Problemi con IPv6 \u2014 a volte un <code>modprobe ipv6<\/code> risolve tutto<\/li>\n<\/ol>\n<h3>Errore 504 Gateway Timeout<\/h3>\n<p>Il backend \u00e8 troppo lento. Aumento i timeout nella configurazione del proxy e verifico le risorse del server.<\/p>\n<h3>Errore 403 Forbidden<\/h3>\n<p>Spesso un problema di permessi sui file o di configurazione del server block. Verifico che la direttiva <code>server_name<\/code> corrisponda esattamente al dominio richiesto.<\/p>\n<h2>Reverse Proxy Nginx con Docker<\/h2>\n<p>Se utilizzate Docker per i vostri servizi, il reverse proxy diventa ancora pi\u00f9 potente. Ogni container gira su una porta interna e Nginx instrada il traffico:<\/p>\n<pre><code># Esempio per due container Docker\nserver {\n    listen 443 ssl http2;\n    server_name app1.example.com;\n\n    location \/ {\n        proxy_pass http:\/\/172.17.0.2:8080;\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    }\n}\n\nserver {\n    listen 443 ssl http2;\n    server_name app2.example.com;\n\n    location \/ {\n        proxy_pass http:\/\/172.17.0.3:9090;\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    }\n}<\/code><\/pre>\n<p>In questo scenario, nessun container ha bisogno di esporre le porte direttamente al mondo esterno: tutta la comunicazione passa attraverso il reverse proxy, che gestisce anche SSL e sicurezza.<\/p>\n<h2>FAQ<\/h2>\n<h3>Quanti siti posso gestire con un solo reverse proxy Nginx?<\/h3>\n<p>Non c&#8217;\u00e8 un limite pratico al numero di server block che potete configurare. Nginx \u00e8 estremamente efficiente e nella mia esperienza gestisco tranquillamente 20-30 siti sullo stesso reverse proxy senza problemi. Il collo di bottiglia sar\u00e0 la RAM e la CPU del server, non Nginx.<\/p>\n<h3>Il reverse proxy Nginx rallenta il sito?<\/h3>\n<p>No, anzi. Nginx aggiunge un overhead trascurabile (millisecondi) e nella pratica <em>migliora<\/em> le performance grazie al buffering, alla compressione e al caching. Il backend viene liberato pi\u00f9 rapidamente perch\u00e9 Nginx gestisce le connessioni lente dei client.<\/p>\n<h3>Posso usare Nginx come reverse proxy davanti ad Apache?<\/h3>\n<p>Assolutamente s\u00ec, ed \u00e8 una configurazione molto comune. Apache gestisce l&#8217;elaborazione PHP e Nginx fa da frontend per SSL termination, caching e servire i file statici. Basta che Apache ascolti su una porta interna diversa dalla 80 (ad esempio 8080).<\/p>\n<h3>Come gestisco i certificati SSL per molti domini?<\/h3>\n<p>Uso Certbot con il plugin Nginx per generare certificati Let&#8217;s Encrypt individuali per ogni dominio. Per i sottodomini uso certificati wildcard con validazione DNS-01. Il rinnovo automatico \u00e8 gestito da un cronjob di Certbot. Se volete approfondire, leggete la mia guida sui <a href=\"https:\/\/darioiannascoli.it\/blog\/cronjob-plesk-backup-manutenzione-server\/\">cronjob per automazione e manutenzione<\/a>.<\/p>\n<h3>Qual \u00e8 la differenza tra reverse proxy e load balancer?<\/h3>\n<p>Un reverse proxy instrada le richieste a uno o pi\u00f9 backend, gestendo SSL, caching e sicurezza. Un load balancer \u00e8 una funzione specifica del reverse proxy che distribuisce il carico tra pi\u00f9 server identici. Nginx pu\u00f2 fare entrambe le cose contemporaneamente tramite i blocchi <em>upstream<\/em>.<\/p>\n<h2>Conclusione<\/h2>\n<p>Configurare un <strong>reverse proxy Nginx<\/strong> per gestire pi\u00f9 siti su un solo server \u00e8 una competenza fondamentale per ogni sysadmin. Come avete visto, il processo non \u00e8 complicato ma richiede attenzione ai dettagli: header corretti, SSL hardening, rate limiting e monitoraggio costante.<\/p>\n<p>Nella mia esperienza quotidiana, questa architettura mi permette di gestire decine di siti e applicazioni in modo efficiente, sicuro e facilmente manutenibile. Ogni volta che aggiungo un nuovo sito, mi basta creare un nuovo server block, generare il certificato SSL e ricaricare Nginx \u2014 il tutto senza alcun downtime.<\/p>\n<p>Se state pensando di migrare la vostra infrastruttura, date un&#8217;occhiata anche al mio articolo su <a href=\"https:\/\/darioiannascoli.it\/blog\/migrare-sito-hosting-senza-downtime\/\">come migro un sito su nuovo hosting senza downtime<\/a> e a quello sulle <a href=\"https:\/\/darioiannascoli.it\/blog\/aumento-prezzi-plesk-2026-alternative-open-source-cloudpanel-1panel-aapanel\/\">alternative open source a Plesk<\/a> per un pannello di controllo gratuito.<\/p>\n<p>Avete domande o volete condividere la vostra configurazione? Scrivetemi nei commenti!<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Guida pratica per configurare Nginx come reverse proxy per gestire pi\u00f9 siti su un solo server, con SSL, sicurezza e performance ottimizzate.<\/p>\n","protected":false},"author":1,"featured_media":1316,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_seopress_robots_primary_cat":"","_seopress_titles_title":"Reverse Proxy Nginx per Pi\u00f9 Siti: Guida Pratica","_seopress_titles_desc":"Configura un reverse proxy Nginx per gestire pi\u00f9 siti su un server: SSL, load balancing, sicurezza e performance. Guida step-by-step testata.","_seopress_robots_index":"","footnotes":""},"categories":[3],"tags":[290,120,233,289,291,47],"class_list":["post-1315","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-hosting","tag-hosting","tag-linux","tag-nginx","tag-reverse-proxy","tag-server","tag-ssl"],"_links":{"self":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/1315","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/comments?post=1315"}],"version-history":[{"count":0,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/1315\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media\/1316"}],"wp:attachment":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media?parent=1315"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/categories?post=1315"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/tags?post=1315"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}