Disponibilità dell'API da diversi paesi: 5 metriche visibili solo con IP esterno

Se il tuo monitoraggio API è in esecuzione su un server in un solo data center, vedi solo una parte del quadro. Un utente in Brasile può ricevere un errore 500, mentre il tuo dashboard a Mosca mostra lo stato verde "tutto funziona". Analizziamo quali 5 metriche di accessibilità non possono essere misurate senza una richiesta tramite un reale IP esterno di un altro paese e come farlo senza una complessa infrastruttura.

Perché il monitoraggio locale inganna

La maggior parte dei team configura il monitoraggio API tramite UptimeRobot, Pingdom o un proprio script cron che invia richieste all'endpoint ogni minuto. Il problema è che queste richieste provengono quasi sempre da uno o due regioni — di solito dagli Stati Uniti o dall'Europa, dove si trovano i server dei servizi di monitoraggio. Se il tuo pubblico è in India, Brasile o nel Sud-Est asiatico, i fornitori locali possono limitare il traffico, il nodo CDN può essere sovraccarico e il DNS può risolversi in un IP obsoleto.

Un altro scenario comune è il geo-blocking a livello di CDN o WAF (Cloudflare, Akamai). Alcune regole di sicurezza bloccano interi range di IP da determinati paesi, e la tua API è fisicamente inaccessibile per parte degli utenti, anche se dal tuo IP d'ufficio tutto funziona perfettamente. Tali problemi non possono essere diagnosticati se si testa solo da un punto.

Un terzo scenario è il bilanciamento del carico tramite Anycast o edge CDN regionali. Una richiesta dalla Germania può arrivare a un nodo, mentre da Singapore a un altro completamente diverso, con una versione di cache o configurazione differente. La differenza nel comportamento dell'API tra le regioni non è una teoria, ma una realtà con cui i team si confrontano regolarmente, avendo utenti distribuiti in tutto il mondo.

5 metriche di accessibilità visibili solo tramite IP esterno

Di seguito sono riportate cinque metriche che mostrano il quadro reale dell'accessibilità solo quando la richiesta viene eseguita da un indirizzo IP fisicamente situato nel paese target o almeno instradato attraverso la sua rete.

1. Tempo di risposta (Latency / RTT)

Il Round-Trip Time è il tempo che intercorre dall'invio della richiesta alla ricezione del primo pacchetto di risposta. Da un server in Europa, la latenza verso la tua API può essere di 20 ms, mentre un utente dal Sud-Est asiatico dovrà attendere 400-600 ms a causa della distanza geografica e del numero di nodi intermedi (hops). Se non si misura la latenza da diverse regioni, è facile perdere il momento in cui per parte del pubblico il servizio diventa praticamente inutilizzabile — particolarmente critico per le API legate a operazioni in tempo reale: bidding in pubblicità, chat, transazioni fintech.

2. TTFB (Time To First Byte)

Il TTFB mostra quanto tempo impiega il server a elaborare la richiesta prima di iniziare a inviare la risposta. Questa metrica dipende non solo dalla rete, ma anche da quale nodo CDN o bilanciatore gestisce una specifica regione. Spesso accade che un server edge in un paese memorizzi la risposta e la restituisca in 50 ms, mentre in un altro paese la richiesta raggiunge ogni volta il server di origine e viene elaborata nuovamente, impiegando 800 ms o più. La differenza nel TTFB tra le regioni è un chiaro segnale di problemi con la configurazione del CDN o di una copertura insufficiente dei nodi edge.

3. Tempo di risoluzione DNS

La risoluzione DNS è una fonte separata di ritardi ed errori, che dipende completamente dal risolutore locale dell'utente. Se hai configurato GeoDNS (diverse A-record a seconda della regione della richiesta), un errore nella configurazione può portare gli utenti di un paese a risolversi su un data center su un altro continente — con un enorme ritardo. Questo problema è visibile solo quando si effettua una richiesta di risoluzione DNS da un vero IP del paese target; un test locale si risolverà sempre "correttamente" rispetto alla tua posizione geografica.

4. Percentuale di richieste riuscite (Uptime) per regione

Un uptime del 99.9% su un dashboard di monitoraggio che invia richieste da un solo punto non garantisce il 99.9% per gli utenti in un altro paese. I fornitori locali possono avere problemi di peering specificamente con il tuo fornitore di hosting, con il risultato che parte delle richieste dal paese X scade per timeout, mentre il resto del mondo non nota affatto il problema. Per vedere il reale uptime, è necessario contare le richieste riuscite e non riuscite separatamente per ogni regione, e non in modo aggregato.

5. Differenze nei contenuti e nei codici di stato (geo-blocking e personalizzazione)

La quinta metrica non riguarda la velocità, ma il contenuto stesso della risposta. L'API può restituire un 403 Forbidden per determinati paesi a causa delle regole WAF, restituire un insieme di dati ridotto a causa di limitazioni di licenza, o mostrare una versione diversa del contenuto a causa di A/B test legati alla geolocalizzazione. Se si testa l'API solo dal proprio IP, tali differenze rimarranno completamente inosservate — e sono proprio queste a diventare più spesso la causa di lamentele da parte degli utenti di specifiche regioni.

Come impostare il monitoraggio da diversi paesi

La logica di configurazione è semplice: invii la stessa richiesta HTTP alla tua API da più punti contemporaneamente, registri tutte e cinque le metriche e confronti i risultati. Passo dopo passo, appare così:

1. Compila un elenco di paesi prioritari — di solito sono i primi 5 paesi per volume di traffico o fatturato.
2. Per ogni paese, prepara un punto di uscita con un vero IP di quel paese (server proxy o server fisico).
3. Configura uno script o un servizio che invia la stessa richiesta attraverso ogni punto a intervalli prestabiliti (ad esempio, ogni 5 minuti).
4. Registra tutte e 5 le metriche separatamente per ogni paese in un database o in un sistema di metriche (Grafana, Prometheus, ClickHouse).
5. Imposta avvisi per deviazioni delle metriche dal livello di base — ad esempio, se la latenza da un paese specifico è aumentata di 3 volte in un'ora.

Il punto chiave è proprio il punto 2. Senza un'uscita reale nel paese desiderato, tutti gli altri passaggi sono privi di senso, perché le metriche misureranno non ciò che vede l'utente, ma ciò che vede il tuo stesso server di monitoraggio.

Quale tipo di proxy scegliere per il monitoraggio

Per costruire un monitoraggio geograficamente distribuito, si utilizzano più frequentemente i server proxy — è più economico e veloce che affittare server fisici o VPS in ogni paese necessario. La scelta del tipo di proxy dipende da cosa vuoi misurare.

Tipo di proxy	Quando utilizzare	Caratteristiche
Proxy di data center	Controllo di base dell'accessibilità e latenza, quando non è necessaria l'imitazione di un utente reale	Alta velocità, basso costo, ma l'IP è facilmente identificabile come di data center — non adatto per testare il geo-blocking per fornitori
Proxy residenziali	Controllo di ciò che vede un utente reale con un fornitore domestico	L'IP appartiene a fornitori reali in un paese specifico, riflette più accuratamente la instradazione e le regole WAF
Proxy mobili	Test di accessibilità API per applicazioni mobili e traffico mobile	IP da reti di operatori mobili, mostra ritardi e blocchi specifici per il traffico mobile

Se la tua API serve principalmente traffico web da desktop e server, per costruire un monitoraggio di base sono sufficienti i proxy di data center — forniscono una velocità stabile e una latenza prevedibile. Ma se è necessario controllare esattamente ciò con cui si confronta un utente reale — comprese le regole di geo-blocking impostate in base all'ASN del fornitore — è opportuno utilizzare proxy residenziali, poiché sono instradati attraverso le reti dei normali fornitori di internet dello stesso paese. Per applicazioni mobili e SDK che effettuano richieste all'API, è ragionevole aggiungere controlli tramite proxy mobili, poiché gli operatori mobili utilizzano spesso NAT e le proprie regole di instradazione, diverse da quelle della rete domestica.

Script pronto in Python per la raccolta delle metriche

Di seguito è riportato un esempio semplificato di uno script che invia una richiesta tramite proxy nel paese specificato e raccoglie quattro delle cinque metriche (le differenze nei contenuti devono essere confrontate separatamente, abbinando le risposte). Lo script utilizza la libreria requests e il modulo socket per misurare il tempo di risoluzione DNS.

import time
import socket
import requests

def measure_api(url, proxy, country_label):
    hostname = url.split("//")[1].split("/")[0]

    # 1. Tempo di risoluzione DNS
    dns_start = time.time()
    try:
        socket.gethostbyname(hostname)
    except socket.gaierror:
        pass
    dns_time = time.time() - dns_start

    proxies = {
        "http": proxy,
        "https": proxy,
    }

    try:
        start = time.time()
        response = requests.get(
            url,
            proxies=proxies,
            timeout=10,
            stream=True
        )
        ttfb = time.time() - start  # TTFB approssimato

        full_load_time = time.time() - start
        status_code = response.status_code
        success = status_code == 200

        result = {
            "country": country_label,
            "dns_time_ms": round(dns_time * 1000, 2),
            "ttfb_ms": round(ttfb * 1000, 2),
            "total_time_ms": round(full_load_time * 1000, 2),
            "status_code": status_code,
            "success": success,
        }
    except requests.exceptions.RequestException as e:
        result = {
            "country": country_label,
            "dns_time_ms": round(dns_time * 1000, 2),
            "ttfb_ms": None,
            "total_time_ms": None,
            "status_code": None,
            "success": False,
            "error": str(e),
        }

    return result


# Esempio di utilizzo con proxy da diversi paesi
endpoints = [
    {"label": "Germany", "proxy": "http://user:[email protected]:port"},
    {"label": "Brazil", "proxy": "http://user:[email protected]:port"},
    {"label": "Singapore", "proxy": "http://user:[email protected]:port"},
]

API_URL = "https://api.yourservice.com/health"

for ep in endpoints:
    data = measure_api(API_URL, ep["proxy"], ep["label"])
    print(data)

Per la versione di produzione di tale script, è opportuno aggiungere la registrazione dei risultati in un database (ad esempio, ClickHouse o InfluxDB), la visualizzazione tramite Grafana e avvisi tramite bot Telegram o webhook Slack al superamento dei valori soglia. È meglio eseguire lo script tramite cron o un pianificatore di attività con un intervallo di 5-15 minuti per ogni paese.

Se hai bisogno di un controllo rapido senza scrivere codice, una richiesta simile può essere eseguita tramite cURL misurando il tempo:

curl -x http://user:[email protected]:port \
  -o /dev/null -s -w "DNS: %{time_namelookup}s | TTFB: %{time_starttransfer}s | Totale: %{time_total}s | HTTP: %{http_code}\n" \
  https://api.yourservice.com/health

Come interpretare i risultati

Dopo aver raccolto dati da tutti i paesi per almeno una settimana, si ottiene un livello di base (baseline) per ogni regione. Successivamente, è necessario guardare non ai numeri assoluti, ma alle deviazioni da questo baseline. Se la latenza dal Brasile si mantiene stabilmente a 350 ms — è normale per quella geografia, e l'allerta dovrebbe scattare se il valore cresce improvvisamente a 1500 ms. Analogamente per l'uptime: 99.5% per una regione complessa con internet instabile può essere una norma accettabile, mentre un calo al 95% è già un segnale di problema da parte del fornitore o del CDN.

Un'attenzione particolare deve essere dedicata ai codici di stato 403 e 451 — indicano quasi sempre geo-blocking da parte di WAF o CDN, e non un problema con l'API stessa. Se tali codici appaiono solo da un paese specifico e solo utilizzando proxy di un certo tipo (ad esempio, di data center), ciò può significare che il blocco è impostato in base al criterio "IP simile a un data center", e non in base alla reale geolocalizzazione — in questo caso, il test con proxy residenziali fornirà un quadro più onesto.

Servizi pronti vs soluzione personalizzata

Se non vuoi mantenere il tuo script, ci sono servizi pronti di monitoraggio sintetico con punti di presenza in diversi paesi: Pingdom, Uptrends, Site24x7, Checkly. Questi eliminano la necessità di configurare l'infrastruttura, ma di solito sono limitati a un insieme fisso di posizioni e non offrono flessibilità nella scelta del tipo di IP (residenziale, mobile, data center) per un test specifico.

Una soluzione personalizzata basata su proxy offre maggiore controllo: puoi testare esattamente quei paesi che sono importanti per il tuo business, passare tra i tipi di IP per diagnosticare problemi specifici (ad esempio, geo-blocking per ASN) e integrare le metriche direttamente nel tuo sistema di monitoraggio senza intermediari. Una combinazione di entrambi gli approcci è un equilibrio ragionevole: servizi pronti per il monitoraggio SLA di base, script personalizzati con proxy per la diagnosi mirata dei problemi in regioni specifiche.

Conclusione

Il monitoraggio locale da un solo punto mostra solo una parte della verità sull'accessibilità dell'API. Per vedere il quadro reale, è necessario misurare la latenza, il TTFB, il tempo di risoluzione DNS, l'uptime e le differenze nei contenuti separatamente per ogni paese — e farlo tramite un IP che è realmente instradato attraverso la rete della regione target. Senza questo, è facile perdere un problema che impedisce a parte degli utenti di utilizzare il servizio, mentre il dashboard mostra "tutto verde".

Per costruire tale monitoraggio, i proxy residenziali sono i più adatti se è importante vedere esattamente ciò che vede un utente reale con internet domestico in un paese specifico. Per un controllo di base più economico e veloce, sono adatti i proxy di data center, mentre per diagnosticare problemi specifici con il pubblico mobile, è opportuno aggiungere controlli tramite proxy mobili. Questo approccio combinato fornisce un quadro completo di come appare la tua API da qualsiasi punto del mondo, e non solo dal server dove è distribuita.