{"id":35939,"date":"2019-10-31T22:07:41","date_gmt":"2019-10-31T19:07:41","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-my-probivali-velikij-kitajskij-faervol-ch-1\/"},"modified":"2019-10-31T22:07:41","modified_gmt":"2019-10-31T19:07:41","slug":"kak-my-probivali-velikij-kitajskij-faervol-ch-1","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kak-my-probivali-velikij-kitajskij-faervol-ch-1","title":{"rendered":"Come abbiamo superato il Grande Firewall Cinese (parte 1)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Ciao a tutti!<\/p>\n<p><\/p>\n<p>In contatto, Nikita \u2014 ingegnere di sistema di <strong>SEMrush<\/strong>. Oggi vi racconter\u00f2 come abbiamo affrontato il compito di garantire la stabilit\u00e0 del nostro servizio semrush.com in Cina e quali problemi abbiamo incontrato nel corso della sua realizzazione (considerando la posizione del nostro data center sulla costa orientale degli Stati Uniti).<\/p>\n<p><\/p>\n<p>Questa sar\u00e0 una grande storia, suddivisa in pi\u00f9 articoli. Vi racconter\u00f2 come \u00e8 andata: da un servizio completamente non funzionante dalla Cina, a prestazioni comparabili a quelle della sua versione americana per gli Stati Uniti. Prometto, sar\u00e0 interessante e utile. Quindi, iniziamo.<\/p>\n<p><\/p>\n<h2 id=\"problemy-kitayskogo-interneta\">Problemi di internet in Cina<\/h2>\n<p><\/p>\n<p>Anche la persona pi\u00f9 lontana dalla specificit\u00e0 dell'amministrazione di rete ha sentito parlare almeno una volta di <strong>Grande Firewall Cinese<\/strong>. Uhm, sembra interessante, vero? Ma cos'\u00e8 esattamente e come funziona realmente \u2014 la questione \u00e8 piuttosto complessa. Su internet si possono trovare molti articoli su questo argomento, ma dal punto di vista tecnico il funzionamento di questo firewall non viene descritto da nessuna parte. Non sorprende, in effetti. Devo ammettere che, dopo un anno di utilizzo, non posso dire esattamente come funziona, ma posso condividere le mie osservazioni e conclusioni pratiche. Cominceremo con i rumor su questo firewall.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Ci sono molti rumor su questo firewall. Raccogliamo i principali e pi\u00f9 interessanti in un'unica lista:<\/p>\n<p><\/p>\n<ul>\n<li>Google, Facebook, Twitter e altri servizi simili sono bloccati e non funzionano in Cina.<\/li>\n<li>Qualsiasi traffico che va Oltre i confini della Cina e Viene in Cina viene analizzato e limitato tramite machine learning (in caso di traffico sospetto), il che ne rallenta notevolmente il passaggio attraverso la frontiera.<\/li>\n<li>I servizi segreti cinesi possono hackerare qualsiasi traffico crittografato che passa attraverso il loro firewall.<\/li>\n<li>I tunnel VPN e i tunnel IPSEC sono instabili, cadono e vengono continuamente bloccati.<\/li>\n<li>Pi\u00f9 \u00e8 semplice la crittografia, pi\u00f9 semplice \u00e8 la pass phrase utilizzata per l'autenticazione\/cifratura del traffico, pi\u00f9 velocemente supera il firewall cinese.<\/li>\n<\/ul>\n<p><\/p>\n<p>Ecco cosa siamo riusciti a scoprire su queste voci:<\/p>\n<p><\/p>\n<ul>\n<li>Google, Facebook, Twitter e altri servizi simili sono effettivamente bloccati (il tuo K.O.), ma molti domini tecnici di Google, ad esempio, non sono vietati e funzionano (come gstatic.com). Da ci\u00f2 ne deriva che non \u00e8 saggio eliminare indiscriminatamente tutte le risorse di Google e simili che sembrano bloccate.<\/li>\n<li>Qualsiasi traffico che attraversa il confine aggiunge davvero un notevole ritardo al suo tempo. Guarda i due risultati. Un sito, una pagina, semplice GET <em>curl<\/em>Il primo rilevamento proviene dalla Cina stessa (bellissima citt\u00e0 di Shenzhen). Il secondo ricordo dall'esterno da Hong Kong (ha sovranit\u00e0 e non c'\u00e8 firewall tra lui e il mondo). La distanza tra le citt\u00e0 in linea retta \u00e8 di circa 30-40 km.<\/li>\n<\/ul>\n<p><\/p>\n<pre><code class=\"bash\">nikita@china-shenzhen:~# curl -o \/dev\/null -w@curl_time \"https:\/\/www.semrush.com\/info\/ebay.com\"\n  % Totale    % Ricevuto % Trasferito  Velocit\u00e0 Media   Tempo    Tempo     Tempo  Corrente\n                                 Scarica  Carica   Totale   Trascorso    Rimanente  Velocit\u00e0\n100  381k    0  381k    0     0  71824      0 --:--:--  0:00:05 --:--:-- 82832\ntempo_namelookup:  0.004500\ntempo_connect:  0.169342\ntempo_appconnect:  0.723189\ntempo_pretransfer:  0.723499\ntempo_redirect:  0.000000\ntempo_starttransfer:  1.532912\n----------\ntempo_total:  5.443407\n----------\nsize_download:  390968 Bytes\nspeed_download:  71824.000B\/s\n\nnikita@china-hongkong:~# curl -o \/dev\/null -w@curl_time \"https:\/\/www.semrush.com\/info\/ebay.com\"\n  % Totale    % Ricevuto % Trasferito  Velocit\u00e0 Media   Tempo    Tempo     Tempo  Corrente\n                                 Scarica  Carica   Totale   Trascorso    Rimanente  Velocit\u00e0\n100  319k    0  319k    0     0  2555k      0 --:--:-- --:--:-- --:--:-- 2573k\ntempo_namelookup:  0.029366\ntempo_connect:  0.030742\ntempo_appconnect:  0.047310\ntempo_pretransfer:  0.047388\ntempo_redirect:  0.000000\ntempo_starttransfer:  0.120793\n----------\ntempo_total:  0.124871\n----------\nsize_download:  326755 Bytes\nspeed_download:  2616740.000B\/s<\/code><\/pre>\n<p><\/p>\n<p>Fai attenzione a <strong>tempo_connect<\/strong>. In generale, puoi vedere il risultato: il firewall aggiunge 4 secondi extra, il che \u00e8 incredibilmente lungo.<\/p>\n<p><\/p>\n<ul>\n<li>VPN e tunnel IPSEC spesso subiscono interruzioni. Ne parler\u00f2 pi\u00f9 in dettaglio pi\u00f9 avanti. <\/li>\n<li>C'\u00e8 un'opinione, proveniente da persone che vivono in Cina, secondo cui pi\u00f9 semplice \u00e8 la crittografia del traffico, pi\u00f9 velocemente esso passa il confine, perch\u00e9 \u00e8 facile capire che non contiene nulla di illegale. Allo stesso modo, il traffico \"pulito\" riceve pi\u00f9 banda e velocit\u00e0 di transito, mentre il traffico \"sporco\", in cui nulla \u00e8 comprensibile, ha al contrario un passaggio pi\u00f9 lento. Come esempio, presenter\u00f2 curl fino a <em>ifconfig.co<\/em> tramite i protocolli HTTPS e HTTP. <\/li>\n<\/ul>\n<p><\/p>\n<pre><code class=\"bash\">curl -o \/dev\/null -w@curl_time \"https:\/\/ifconfig.co\/\"\n  % Totale    % Ricevuto % Trasferito Velocit\u00e0 Media   Tempo    Tempo     Tempo  Corrente\n                                 Scaricati  Caricati   Totale   Speso    Rimasto  Velocit\u00e0\n100    13  100    13    0     0      2      0  0:00:06  0:00:05  0:00:01     3\ntempo_namelookup:  0.004305\ntempo_connect:  0.397465\ntempo_appconnect:  5.149305\ntempo_pretransfer:  5.149393\ntempo_redirect:  0.000000\ntempo_starttransfer:  5.568847\n----------\ntempo_totale:  5.568893\n----------\nsize_download:  13 Bytes\nspeed_download:  2.000B\/s\n\ncurl -o \/dev\/null -w@curl_time \"http:\/\/ifconfig.co\/\"\n  % Totale    % Ricevuto % Trasferito Velocit\u00e0 Media   Tempo    Tempo     Tempo  Corrente\n                                 Scaricati  Caricati   Totale   Speso    Rimasto  Velocit\u00e0\n100    13  100    13    0     0     28      0 --:--:-- --:--:-- --:--:--    28\ntempo_namelookup:  0.004282\ntempo_connect:  0.212457\ntempo_appconnect:  0.000000\ntempo_pretransfer:  0.212484\ntempo_redirect:  0.000000\ntempo_starttransfer:  0.450565\n----------\ntempo_totale:  0.450620\n----------\nsize_download:  13 Bytes\nspeed_download:  28.000B\/s<\/code><\/pre>\n<p><\/p>\n<p>La differenza di 5 secondi sul tempo totale di caricamento di 13 byte. Facendo questo test pi\u00f9 volte, si pu\u00f2 notare che una richiesta GET su HTTP si completa generalmente in un tempo simile ogni volta, mentre su HTTPS il sito risponde talvolta in 3, 5, 10 e persino 17 secondi. A volte si verificano errori SSL:<\/p>\n<p><\/p>\n<p><code>Errore sconosciuto del protocollo SSL nella connessione a ifconfig.co:443.<\/code><\/p>\n<p><\/p>\n<p>Quindi, cosa abbiamo:<\/p>\n<p><\/p>\n<ul>\n<li>Problemi creati dal firewall cinese, come descritto sopra.<\/li>\n<li>I ping verso risorse esterne e all'interno dei tunnel scompaiono periodicamente.<\/li>\n<li>La latenza tra due punti cambia costantemente, e spesso \u00e8 semplicemente imprevedibile. Collegando diverse citt\u00e0\/regioni, ti aspetti che, in base alla posizione geografica dei regioni, la latenza sia minore, ma ottieni esattamente il contrario. <\/li>\n<li>Internet e le linee di comunicazione funzionano a volte rapidamente, a volte lentamente. C'\u00e8 una leggera dipendenza dall'ora del giorno e dal giorno della settimana, ma non sempre.<\/li>\n<li>Le richieste DNS verso l'esterno dalla Cina a volte superano il timeout consentito.<\/li>\n<\/ul>\n<p><\/p>\n<p>Il quadro si delinea semplicemente \"ottimo\". <\/p>\n<p><\/p>\n<p>Il nostro data center, come ho gi\u00e0 detto, si trova nell'est degli Stati Uniti, e SEMrush \u00e8 composto da decine di prodotti interconnessi, backend, frontend, database, e tutto questo \u00e8 presente nei data center e nel cloud. Il nostro compito, come team di amministratori di sistema, era quello di avviare rapidamente le operazioni in Cina con sforzi minimi.<\/p>\n<p><\/p>\n<p>Ci siamo posti una domanda importante: \u00e8 possibile affrontare le problematiche legate a Internet e al firewall cinese con un approccio a basso impatto, a livello di rete\/cloud\/server?<\/p>\n<p><\/p>\n<p>Abbiamo iniziato a ottenere <noindex><a rel=\"nofollow\" href=\"https:\/\/ru.wikipedia.org\/wiki\/%D0%9B%D0%B8%D1%86%D0%B5%D0%BD%D0%B7%D0%B8%D1%8F_ICP\"><strong>licenza ICP<\/strong>-licenza<\/a><\/noindex>.<\/p>\n<p><\/p>\n<h2 id=\"icp-licenziya\">licenza ICP<\/h2>\n<p><\/p>\n<p>Per poter ospitare il proprio servizio in Cina continentale e condurre test, \u00e8 necessario prima ottenere una licenza ICP per il dominio.<\/p>\n<p><\/p>\n<p>Se il traffico degli utenti del tuo sito viene terminato all'interno della Cina continentale e se il tuo dominio non possiede una licenza ICP, il tuo traffico verr\u00e0 bloccato dal provider\/hosting. \u00c8 interessante notare che nella licenza ICP \u00e8 registrato un provider specifico, sia esso Cloudflare o Alibaba Cloud. Pertanto, se hai ottenuto una licenza ICP per Cloudflare e hai ospitato il tuo sito presso di loro, successivamente non sar\u00e0 possibile trasferirlo \"senza soluzione di continuit\u00e0\" su Alibaba Cloud. Sar\u00e0 necessario aggiungere un altro hosting a questa licenza.<\/p>\n<p><\/p>\n<p>Ottenendo una licenza ICP per il dominio, siamo stati in grado di pensare e realizzare idee e soluzioni tecniche specifiche.<\/p>\n<p><\/p>\n<h2 id=\"testirovanie-resheniy\">Test delle soluzioni<\/h2>\n<p><\/p>\n<p>Ma prima di creare direttamente le opzioni di staging, regolare le impostazioni e ottimizzare il funzionamento del sito e la sua velocit\u00e0, \u00e8 necessario scegliere uno strumento per il test, per vedere quali delle nostre azioni migliorano o al contrario peggiorano le performance del sito.<\/p>\n<p><\/p>\n<p>Il nostro strumento di test doveva soddisfare due requisiti principali:<\/p>\n<p><\/p>\n<ul>\n<li>doveva essere in grado di eseguire test dalla Cina,<\/li>\n<li>doveva avere test basati su browser.<\/li>\n<\/ul>\n<p><\/p>\n<p>Cos\u00ec abbiamo trovato <noindex><a rel=\"nofollow\" href=\"https:\/\/www.catchpoint.com\/\">Catchpoint<\/a><\/noindex>! Hanno una copertura eccellente dei punti di test in tutto il mondo. In Cina, con questo strumento \u00e8 possibile eseguire test anche da 100500 province. In ognuna ci sono diversi fornitori + possibilit\u00e0 di fare <strong>Backbone<\/strong>-test (qualcosa come una macchina virtuale in un data center) e <strong>Lastmile<\/strong>-test (il pi\u00f9 vicino possibile alle condizioni degli utenti, aka workstation). L'ultimo tipo di test \u00e8 pi\u00f9 costoso.<\/p>\n<p><\/p>\n<p>Firmando un contratto annuale (non si pu\u00f2 fare di meno), abbiamo iniziato a esplorare lo strumento. Devo ammettere che siamo stati piacevolmente sorpresi dalle sue funzionalit\u00e0. \u00c8 possibile eseguire:<\/p>\n<p><\/p>\n<ul>\n<li>test DNS,<\/li>\n<li>test web (browser, semplice GET\/POST, emulazione di un client mobile, ecc.),<\/li>\n<li>verifiche transazionali (ad esempio, il login),<\/li>\n<li>test API,<\/li>\n<li>Ping, traceroute, NTP, ecc.<\/li>\n<\/ul>\n<p><\/p>\n<p>Non si pu\u00f2 elencare tutto. E la cosa pi\u00f9 importante \u00e8 che ogni test pu\u00f2 essere personalizzato in modo piuttosto buono, aggiungendo un insieme di intestazioni e altri parametri. Alla fine si ottiene un'enorme quantit\u00e0 di informazioni che descrivono completamente il tuo test. Parlando dei pi\u00f9 interessanti per noi (test browser), il risultato include:<\/p>\n<p><\/p>\n<ul>\n<li>Connect, Wait, Load, SSL, tempo DNS,<\/li>\n<li>TTFB, TTLB, Document complete, Render time, DOM load,<\/li>\n<li>Risposta (qualcosa vicino a Time To First Byte), Risposta della pagina web (qualcosa vicino a Time To Last Byte),<\/li>\n<li>Qualsiasi percentile, Tempo medio, Mediana<\/li>\n<li>E simili.<\/li>\n<\/ul>\n<p><\/p>\n<p>Di conseguenza, tutte queste metriche aiutano a vedere i cambiamenti e a capire se le cose siano migliorate. Abbiamo principalmente esaminato <strong>Risposta, Risposta della pagina web, Mediana, 75\u00b0 e 95\u00b0 Percentili<\/strong>. <\/p>\n<p><\/p>\n<p>Una domanda importante che aleggiava fin dall'inizio: <strong>si pu\u00f2 fidare di Catchpoint?<\/strong>? \u041e\u0442\u0440\u0430\u0436\u0430\u0435\u0442 \u043b\u0438 \u044d\u0442\u043e\u0442 \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442 \u0440\u0435\u0430\u043b\u044c\u043d\u0443\u044e \u0441\u043a\u043e\u0440\u043e\u0441\u0442\u044c \u0437\u0430\u0433\u0440\u0443\u0437\u043a\u0438 \u0441\u0430\u0439\u0442\u0430 \u0432 \u041a\u0438\u0442\u0430\u0435 \u0438\u0437 \u0440\u0430\u0437\u043d\u044b\u0445 \u0433\u043e\u0440\u043e\u0434\u043e\u0432 \u0438\u043b\u0438 \u0436\u0435 \u044d\u0442\u043e \u043f\u0440\u043e\u0441\u0442\u043e \u043a\u0430\u043a\u043e\u0439-\u0442\u043e \u0442\u0435\u0441\u0442 \u0432 \u0432\u0430\u043a\u0443\u0443\u043c\u0435, \u043d\u0435 \u0438\u043c\u0435\u044e\u0449\u0438\u0439 \u043d\u0438\u0447\u0435\u0433\u043e \u043e\u0431\u0449\u0435\u0433\u043e \u0441 real user experience?<br \/>\nQuesto \u00e8 un grande problema, perch\u00e9 essere in Russia rende praticamente impossibile sapere con certezza come funziona un sito dalla Cina. Utilizzando un socks-proxy tramite una macchina virtuale, ci si ritrova a caricare il sito per un paio di minuti, il che \u00e8 inaccettabile per i test; quindi, l'unica opzione di test manuale rimane curl e semplici GET dalla console misurando il tempo. Questo aiuta, perch\u00e9 il test riflette bene la velocit\u00e0 della soluzione di rete, e se ci sono anche test browser, \u00e8 ancora meglio.<\/p>\n<p><\/p>\n<p>In seguito, siamo andati in Cina e abbiamo riscontrato che <strong>ci si pu\u00f2 fidare di Catchpoint, che riflette abbastanza accuratamente i reali indicatori di velocit\u00e0.<\/strong><\/p>\n<p><\/p>\n<h2 id=\"cloudflare-china-network\">Cloudflare China Network<\/h2>\n<p><\/p>\n<p>Poich\u00e9 per il dominio principale semrush.com utilizziamo con successo Cloudflare, abbiamo deciso di provare subito la loro funzionalit\u00e0 chiamata <noindex><a rel=\"nofollow\" href=\"https:\/\/www.cloudflare.com\/network\/china\/\">China Network<\/a><\/noindex>. Questa opzione \u00e8 attivabile solo per siti web Enterprise su richiesta separata e a pagamento. \u00c8 inoltre disponibile solo per siti con una licenza ICP valida, in cui Cloudflare \u00e8 indicato come fornitore. Una volta attivata, il sito avr\u00e0 accesso al \u201cCDN cinese\u201d di Cloudflare \u2014 il traffico proveniente dalle regioni cinesi raggiunge i PoP (Points of Presence) pi\u00f9 vicini di CF, e da l\u00ec viene inoltrato attraverso le proprie reti o quelle dei fornitori\/partner fino all'origine. <\/p>\n<p><\/p>\n<p>Lo schema di questo banco di prova \u00e8 mostrato di seguito.<\/p>\n<p><\/p>\n<p>Per noi \u00e8 un'ottima soluzione. Si scopre che il secondo dominio sar\u00e0 anch'esso sotto CF, il che non aumenta il numero di soluzioni utilizzate in azienda e praticamente non complica l'infrastruttura.<\/p>\n<p><\/p>\n<p>Abbiamo lanciato i test del browser, ecco i risultati:<\/p>\n<p><\/p>\n<p>I rombi rossi indicano i test falliti. I fallimenti in basso sono errori DNS (timeout di risoluzione). I fallimenti in alto sono timeout.<\/p>\n<p><\/p>\n<p><em>Uptime: 86,6<br \/>\nMediana: 18s<br \/>\n75\u00b0 Percentile: 29,3s<br \/>\n95\u00b0 Percentile: 60s<\/em><\/p>\n<p><\/p>\n<p>Mediana, dopo aver rimosso il carico <em>reCaptcha<\/em> (servizio di Google, bloccato in Cina), \u00e8 diminuito da 28 a 18 secondi. Tuttavia, questi sono punteggi terribili, considerando che lo stesso test su semrush.com (degli USA) ha dato meno di 10 secondi per il 95% degli utenti (degli USA) sulla stessa pagina (statica + dinamica).<\/p>\n<p><\/p>\n<p>Puoi accedere a ogni test e visualizzarlo. <em>Waterfall<\/em> e altri parametri pi\u00f9 dettagliati. Abbiamo iniziato a indagare sulle cause degli errori e se per i timeout \u00e8 tutto pi\u00f9 o meno chiaro: internet in Cina \u201csi interrompe e riprende\u201d, a causa di ci\u00f2 la velocit\u00e0 di connessione e il caricamento delle risorse dall'estero sono instabili e variabili, invece gli errori DNS ci hanno sorpreso molto. Abbiamo scoperto che <em>PoP<\/em> di Cloudflare si trovano effettivamente in Cina, l'indirizzo del sito viene risolto in un IP anycast, ma i server DNS utilizzati sono americani, il che costringe le richieste DNS a passare attraverso il confine, motivo per cui a volte falliscono.<\/p>\n<p><\/p>\n<p>Chiedendo chiarimenti a CF, abbiamo scoperto che <strong>non hanno server DNS propri in Cina<\/strong>, e non si sa ancora quando ci saranno.<\/p>\n<p><\/p>\n<p>Pertanto, abbiamo deciso di testare solo DNS di Cloudflare e abbiamo cambiato il meccanismo di funzionamento di Cloudflare per il nostro sito nella modalit\u00e0 \u201c<strong>Solo DNS<\/strong>\u201d. Questa \u00e8 una modalit\u00e0 in cui Cloudflare non proxy il traffico, il che significa che non fornisce protezione DDoS, CDN e altre funzionalit\u00e0, e funziona come un normale server DNS. <\/p>\n<p><\/p>\n<p>Questo stand \u00e8 schematicamente rappresentato nel disegno seguente. Nel disegno sono considerate le nuove conoscenze che indicano che i server DNS di Cloudflare si trovano dietro un firewall.<\/p>\n<p><\/p>\n<p>In Catchpoint abbiamo avviato semplici test GET (non da browser), che hanno mostrato molti fallimenti. La causa erano gli stessi errori DNS.<\/p>\n<p><\/p>\n<p>Abbiamo iniziato a debuggare questi errori con <em>dig<\/em> e abbiamo scoperto che alla prima richiesta l'indirizzo viene determinato correttamente, mentre alla richiesta successiva riceviamo ogni volta <em>SERVFAIL<\/em> e <em>not found<\/em>. Perch\u00e9 mai?<\/p>\n<p><\/p>\n<pre><code class=\"bash\">root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn\nsemrushchina.cn ha indirizzo 220.170.186.192\nHost semrushchina.cn non trovato: 2(SERVFAIL)\nroot@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn\nsemrushchina.cn ha indirizzo 220.170.186.192\nHost semrushchina.cn non trovato: 2(SERVFAIL)\nroot@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn\nsemrushchina.cn ha indirizzo 220.170.186.192\nHost semrushchina.cn non trovato: 2(SERVFAIL)\nroot@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn\nsemrushchina.cn ha indirizzo 220.170.186.192\nHost semrushchina.cn non trovato: 2(SERVFAIL)<\/code><\/pre>\n<p><\/p>\n<p>Non ci sono errori di questo tipo quando si richiedono direttamente i server NS di Cloudflare:<\/p>\n<p><\/p>\n<pre><code class=\"bash\">root@iZwz97n2wgbp61qucbfrjsZ:~# per i in `seq 1 2`; do host semrushchina.cn ray.ns.cloudflare.com.; done\nUtilizzando il server di dominio:\nNome: ray.ns.cloudflare.com.\nIndirizzo: 173.245.59.138#53\nAlias:\n\nsemrushchina.cn ha indirizzo 220.170.186.192\nsemrushchina.cn ha indirizzo 220.170.186.192\nUtilizzando il server di dominio:\nNome: ray.ns.cloudflare.com.\nIndirizzo: 173.245.59.138#53\nAlias:\n\nsemrushchina.cn ha indirizzo 220.170.186.192\nsemrushchina.cn ha indirizzo 220.170.186.192<\/code><\/pre>\n<p><\/p>\n<p>Quindi, il problema \u00e8 lato server DNS \u201clocale\u201d o del provider.<br \/>\nUn'indagine pi\u00f9 approfondita ha mostrato che <em>SERVFAIL<\/em> riceviamo dal risolutore <em>AAAA<\/em>-record. <\/p>\n<p><\/p>\n<p>\u00c8 emerso che, quando si richiedeva a Cloudflare <em>AAAA<\/em>-record che non esiste nel dominio, Cloudflare rispondeva <em>E<\/em>con un record che \u00e8 un errore e non conforme all'RFC. Questo ha causato che il risolutore locale (<em>x.x.x.x<\/em>) non fosse contento, e rispondeva <em>SERVFAIL<\/em>. Questo comportamento \u00e8 chiaramente visibile nei log sottostanti:<\/p>\n<p><\/p>\n<pre><code class=\"bash\">root@iZwz97n2wgbp61qucbfrjsZ:~# dig -t AAAA semrushchina.cn @x.x.x.x\n\n; &lt;&gt; DiG 9.10.3-P4-Ubuntu &lt;&gt; -t AAAA semrushchina.cn @x.x.x.x\n;; global options: +cmd\n;; Got answer:\n;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, status: SERVFAIL, id: 55467\n;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1\n\n;; OPT PSEUDOSECTION:\n; EDNS: version: 0, flags:; udp: 4096\n;; QUESTION SECTION:\n;semrushchina.cn.               IN      AAAA\n\n;; Query time: 334 msec\n;; SERVER: x.x.x.x#53(x.x.x.x)\n;; WHEN: Tue Aug 14 23:38:50 CST 2018\n;; MSG SIZE  rcvd: 44\n\nroot@iZwz97n2wgbp61qucbfrjsZ:~# dig -t AAAA semrushchina.cn @dana.ns.cloudflare.com.\n\n; &lt;&gt; DiG 9.10.3-P4-Ubuntu &lt;&gt; -t AAAA semrushchina.cn @dana.ns.cloudflare.com.\n;; global options: +cmd\n;; Got answer:\n;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, status: NOERROR, id: 63944\n;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1\n;; WARNING: recursion requested but not available\n\n;; OPT PSEUDOSECTION:\n; EDNS: version: 0, flags:; udp: 512\n;; QUESTION SECTION:\n;semrushchina.cn.               IN      AAAA\n\n;; ANSWER SECTION:\nsemrushchina.cn.        300     IN      A       220.170.186.192\n\n;; Query time: 185 msec\n;; SERVER: 173.245.58.105#53(173.245.58.105)\n;; WHEN: Tue Aug 14 23:43:03 CST 2018\n;; MSG SIZE  rcvd: 60\n<\/code><\/pre>\n<p><\/p>\n<p>Abbiamo inviato un bug report a Cloudflare, e lo hanno risolto dopo un po'. \u00c8 stato interessante: attualmente in Cina non c'\u00e8 ancora supporto per IPv6, quindi Cloudflare non poteva fornire il suo indirizzo IPv6 nella risposta alla richiesta. <em>AAAA<\/em>-record. Alla fine, tutto si \u00e8 risolto in modo che per la Cina Cloudflare ha iniziato a rispondere <em>NODATA<\/em> a tali richieste.<\/p>\n<p><\/p>\n<p>Tuttavia, gli errori DNS nei test di Catchpoint sono diminuiti drasticamente, ma non del tutto. Anche i timeout persistono:<\/p>\n<p><\/p>\n<p>E abbiamo iniziato a cercare un'altra soluzione. <\/p>\n<p><\/p>\n<p>Nella prossima parte vi racconter\u00f2 come abbiamo testato il cloud cinese <strong>Alibaba Cloud<\/strong>, come con un po' di &#171;magia&#187; Nginx siamo stati in grado di creare rapidamente PoC (Proof of Concept) di soluzioni, come abbiamo realizzato soluzioni Multi-Cloud, una delle quali alla fine ha contribuito notevolmente ad accelerare il funzionamento del servizio dalla Cina.<\/p>\n<p><\/p>\n<p><strong>Rimanete sintonizzati!<\/strong><\/p>\n<p><\/p>\n<h3 id=\"sleduyuschie-chasti\">Prossime parti<\/h3>\n<p><\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/semrush\/blog\/458840\/\">Parte 2<\/a><\/noindex><\/p>\n<p>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/semrush\/blog\/458602\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442! \u041d\u0430 \u0441\u0432\u044f\u0437\u0438 \u041d\u0438\u043a\u0438\u0442\u0430 \u2014 \u0441\u0438\u0441\u0442\u0435\u043c\u043d\u044b\u0439 \u0438\u043d\u0436\u0435\u043d\u0435\u0440 \u0438\u0437 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 S\u0415Mrush. \u0421\u0435\u0433\u043e\u0434\u043d\u044f \u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0443 \u0432\u0430\u043c \u043e \u0442\u043e\u043c, \u043a\u0430\u043a \u043f\u0435\u0440\u0435\u0434 \u043d\u0430\u043c\u0438 \u0432\u0441\u0442\u0430\u043b\u0430 \u0437\u0430\u0434\u0430\u0447\u0430 \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0438\u0442\u044c \u0441\u0442\u0430\u0431\u0438\u043b\u044c\u043d\u043e\u0441\u0442\u044c \u0440\u0430\u0431\u043e\u0442\u044b \u043d\u0430\u0448\u0435\u0433\u043e \u0441\u0435\u0440\u0432\u0438\u0441\u0430 semrush.com \u0432 \u041a\u0438\u0442\u0430\u0435, \u0438 \u0441 \u043a\u0430\u043a\u0438\u043c\u0438 \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0430\u043c\u0438 \u043c\u044b \u0441\u0442\u043e\u043b\u043a\u043d\u0443\u043b\u0438\u0441\u044c \u0432 \u0445\u043e\u0434\u0435 \u0435\u0435 \u0432\u044b\u043f\u043e\u043b\u043d\u0435\u043d\u0438\u044f (\u0443\u0447\u0438\u0442\u044b\u0432\u0430\u044f \u043c\u0435\u0441\u0442\u043e\u043d\u0430\u0445\u043e\u0436\u0434\u0435\u043d\u0438\u0435 \u043d\u0430\u0448\u0435\u0433\u043e \u0434\u0430\u0442\u0430-\u0446\u0435\u043d\u0442\u0440\u0430 \u043d\u0430 \u0432\u043e\u0441\u0442\u043e\u0447\u043d\u043e\u043c \u043f\u043e\u0431\u0435\u0440\u0435\u0436\u044c\u0435 \u0421\u0428\u0410). \u042d\u0442\u043e \u0431\u0443\u0434\u0435\u0442 \u0431\u043e\u043b\u044c\u0448\u0430\u044f \u0438\u0441\u0442\u043e\u0440\u0438\u044f, \u0440\u0430\u0437\u0431\u0438\u0442\u0430\u044f \u043d\u0430 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-35939","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 4.9.10 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442! \u041d\u0430 \u0441\u0432\u044f\u0437\u0438 \u041d\u0438\u043a\u0438\u0442\u0430 \u2014 \u0441\u0438\u0441\u0442\u0435\u043c\u043d\u044b\u0439 \u0438\u043d\u0436\u0435\u043d\u0435\u0440 \u0438\u0437 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 S\u0415Mrush. \u0421\u0435\u0433\u043e\u0434\u043d\u044f \u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0443 \u0432\u0430\u043c \u043e \u0442\u043e\u043c, \u043a\u0430\u043a \u043f\u0435\u0440\u0435\u0434 \u043d\u0430\u043c\u0438 \u0432\u0441\u0442\u0430\u043b\u0430 \u0437\u0430\u0434\u0430\u0447\u0430 \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0438\u0442\u044c \u0441\u0442\u0430\u0431\u0438\u043b\u044c\u043d\u043e\u0441\u0442\u044c \u0440\u0430\u0431\u043e\u0442\u044b \u043d\u0430\u0448\u0435\u0433\u043e \u0441\u0435\u0440\u0432\u0438\u0441\u0430 semrush.com \u0432 \u041a\u0438\u0442\u0430\u0435, \u0438 \u0441 \u043a\u0430\u043a\u0438\u043c\u0438 \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0430\u043c\u0438 \u043c\u044b \u0441\u0442\u043e\u043b\u043a\u043d\u0443\u043b\u0438\u0441\u044c \u0432 \u0445\u043e\u0434\u0435 \u0435\u0435 \u0432\u044b\u043f\u043e\u043b\u043d\u0435\u043d\u0438\u044f (\u0443\u0447\u0438\u0442\u044b\u0432\u0430\u044f \u043c\u0435\u0441\u0442\u043e\u043d\u0430\u0445\u043e\u0436\u0434\u0435\u043d\u0438\u0435 \u043d\u0430\u0448\u0435\u0433\u043e \u0434\u0430\u0442\u0430-\u0446\u0435\u043d\u0442\u0440\u0430 \u043d\u0430 \u0432\u043e\u0441\u0442\u043e\u0447\u043d\u043e\u043c \u043f\u043e\u0431\u0435\u0440\u0435\u0436\u044c\u0435 \u0421\u0428\u0410). \u042d\u0442\u043e \u0431\u0443\u0434\u0435\u0442 \u0431\u043e\u043b\u044c\u0448\u0430\u044f \u0438\u0441\u0442\u043e\u0440\u0438\u044f, \u0440\u0430\u0437\u0431\u0438\u0442\u0430\u044f \u043d\u0430 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kak-my-probivali-velikij-kitajskij-faervol-ch-1\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 4.9.10\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041a\u0430\u043a \u043c\u044b \u043f\u0440\u043e\u0431\u0438\u0432\u0430\u043b\u0438 \u0412\u0435\u043b\u0438\u043a\u0438\u0439 \u041a\u0438\u0442\u0430\u0439\u0441\u043a\u0438\u0439 \u0424\u0430\u0435\u0440\u0432\u043e\u043b (\u0447.1) | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442! \u041d\u0430 \u0441\u0432\u044f\u0437\u0438 \u041d\u0438\u043a\u0438\u0442\u0430 \u2014 \u0441\u0438\u0441\u0442\u0435\u043c\u043d\u044b\u0439 \u0438\u043d\u0436\u0435\u043d\u0435\u0440 \u0438\u0437 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 S\u0415Mrush. \u0421\u0435\u0433\u043e\u0434\u043d\u044f \u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0443 \u0432\u0430\u043c \u043e \u0442\u043e\u043c, \u043a\u0430\u043a \u043f\u0435\u0440\u0435\u0434 \u043d\u0430\u043c\u0438 \u0432\u0441\u0442\u0430\u043b\u0430 \u0437\u0430\u0434\u0430\u0447\u0430 \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0438\u0442\u044c \u0441\u0442\u0430\u0431\u0438\u043b\u044c\u043d\u043e\u0441\u0442\u044c \u0440\u0430\u0431\u043e\u0442\u044b \u043d\u0430\u0448\u0435\u0433\u043e \u0441\u0435\u0440\u0432\u0438\u0441\u0430 semrush.com \u0432 \u041a\u0438\u0442\u0430\u0435, \u0438 \u0441 \u043a\u0430\u043a\u0438\u043c\u0438 \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0430\u043c\u0438 \u043c\u044b \u0441\u0442\u043e\u043b\u043a\u043d\u0443\u043b\u0438\u0441\u044c \u0432 \u0445\u043e\u0434\u0435 \u0435\u0435 \u0432\u044b\u043f\u043e\u043b\u043d\u0435\u043d\u0438\u044f (\u0443\u0447\u0438\u0442\u044b\u0432\u0430\u044f \u043c\u0435\u0441\u0442\u043e\u043d\u0430\u0445\u043e\u0436\u0434\u0435\u043d\u0438\u0435 \u043d\u0430\u0448\u0435\u0433\u043e \u0434\u0430\u0442\u0430-\u0446\u0435\u043d\u0442\u0440\u0430 \u043d\u0430 \u0432\u043e\u0441\u0442\u043e\u0447\u043d\u043e\u043c \u043f\u043e\u0431\u0435\u0440\u0435\u0436\u044c\u0435 \u0421\u0428\u0410). \u042d\u0442\u043e \u0431\u0443\u0434\u0435\u0442 \u0431\u043e\u043b\u044c\u0448\u0430\u044f \u0438\u0441\u0442\u043e\u0440\u0438\u044f, \u0440\u0430\u0437\u0431\u0438\u0442\u0430\u044f \u043d\u0430 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kak-my-probivali-velikij-kitajskij-faervol-ch-1\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:07:41+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:07:41+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Come abbiamo superato il Grande Firewall Cinese (parte 1) | ProHoster","description":"Ciao a tutti! Sono Nikita, ingegnere di sistema di SEMrush. Oggi vi parler\u00f2 di come ci siamo trovati di fronte alla sfida di garantire la stabilit\u00e0 del nostro servizio semrush.com in Cina e quali problemi abbiamo affrontato durante il suo completamento (considerando che il nostro data center si trova sulla costa est degli Stati Uniti). Questa sar\u00e0 una lunga storia, suddivisa in diversi","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kak-my-probivali-velikij-kitajskij-faervol-ch-1","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041a\u0430\u043a \u043c\u044b \u043f\u0440\u043e\u0431\u0438\u0432\u0430\u043b\u0438 \u0412\u0435\u043b\u0438\u043a\u0438\u0439 \u041a\u0438\u0442\u0430\u0439\u0441\u043a\u0438\u0439 \u0424\u0430\u0435\u0440\u0432\u043e\u043b (\u0447.1) | ProHoster","og:description":"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442! \u041d\u0430 \u0441\u0432\u044f\u0437\u0438 \u041d\u0438\u043a\u0438\u0442\u0430 \u2014 \u0441\u0438\u0441\u0442\u0435\u043c\u043d\u044b\u0439 \u0438\u043d\u0436\u0435\u043d\u0435\u0440 \u0438\u0437 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 S\u0415Mrush. \u0421\u0435\u0433\u043e\u0434\u043d\u044f \u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0443 \u0432\u0430\u043c \u043e \u0442\u043e\u043c, \u043a\u0430\u043a \u043f\u0435\u0440\u0435\u0434 \u043d\u0430\u043c\u0438 \u0432\u0441\u0442\u0430\u043b\u0430 \u0437\u0430\u0434\u0430\u0447\u0430 \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0438\u0442\u044c \u0441\u0442\u0430\u0431\u0438\u043b\u044c\u043d\u043e\u0441\u0442\u044c \u0440\u0430\u0431\u043e\u0442\u044b \u043d\u0430\u0448\u0435\u0433\u043e \u0441\u0435\u0440\u0432\u0438\u0441\u0430 semrush.com \u0432 \u041a\u0438\u0442\u0430\u0435, \u0438 \u0441 \u043a\u0430\u043a\u0438\u043c\u0438 \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0430\u043c\u0438 \u043c\u044b \u0441\u0442\u043e\u043b\u043a\u043d\u0443\u043b\u0438\u0441\u044c \u0432 \u0445\u043e\u0434\u0435 \u0435\u0435 \u0432\u044b\u043f\u043e\u043b\u043d\u0435\u043d\u0438\u044f (\u0443\u0447\u0438\u0442\u044b\u0432\u0430\u044f \u043c\u0435\u0441\u0442\u043e\u043d\u0430\u0445\u043e\u0436\u0434\u0435\u043d\u0438\u0435 \u043d\u0430\u0448\u0435\u0433\u043e \u0434\u0430\u0442\u0430-\u0446\u0435\u043d\u0442\u0440\u0430 \u043d\u0430 \u0432\u043e\u0441\u0442\u043e\u0447\u043d\u043e\u043c \u043f\u043e\u0431\u0435\u0440\u0435\u0436\u044c\u0435 \u0421\u0428\u0410). \u042d\u0442\u043e \u0431\u0443\u0434\u0435\u0442 \u0431\u043e\u043b\u044c\u0448\u0430\u044f \u0438\u0441\u0442\u043e\u0440\u0438\u044f, \u0440\u0430\u0437\u0431\u0438\u0442\u0430\u044f \u043d\u0430 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kak-my-probivali-velikij-kitajskij-faervol-ch-1","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:07:41+00:00","article:modified_time":"2019-10-31T19:07:41+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"35939","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-22 01:21:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:53:31","updated":"2026-01-22 01:21:19"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/35939","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=35939"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/35939\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=35939"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=35939"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=35939"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}