Il tuo Mac a noleggio non sta in una server farm, e per i test è un vantaggio

Un potenziale cliente ci ha fatto due domande sensate prima di iscriversi. Dove sono le macchine, e l’IP in uscita viene geolocalizzato lì? La risposta onesta è che sono in una struttura privata nel New Jersey su fibra business, non in una server farm. Qualche settimana fa ci sembrava una cosa da spiegare scusandoci. Non lo è.

Cosa dicono i database

Abbiamo controllato da una delle macchine, invece di dare le cose per scontate. L’indirizzo in uscita appartiene a un provider di fibra business. Il DNS inverso punta al pool clienti del provider. Due servizi di geolocalizzazione indipendenti concordano sulla classificazione.

isp:      Verizon Business
as:       AS701
hosting:  false
proxy:    false
mobile:   false

Il punto è quell’ultimo blocco. Per ogni sistema che valuta il traffico in base alla provenienza, questo Mac sembra un ufficio, perché è proprio questo.

Perché conta per i test

I sistemi anti-bot e anti-frode trattano con sospetto gli intervalli di indirizzi dei provider di hosting, e hanno ragione. Così i flussi di registrazione, le sandbox di pagamento, la verifica degli annunci, i panel di sondaggi e i servizi basati sulla posizione si comportano tutti in modo diverso quando la richiesta arriva da un IP cloud. Un test che passa dal portatile di uno sviluppatore e fallisce in CI molto spesso è solo questo.

Il primo cliente che ce l’ha chiesto fa QA su iOS. I suoi test parlano con servizi in produzione che si comportano diversamente con il traffico cloud. Per quel lavoro, un Mac su una normale linea business non è un compromesso. È il requisito.

Controlla il tuo traffico in uscita

Puoi verificare la classificazione di qualsiasi macchina in un minuto, dalla macchina stessa. Questi sono i comandi esatti che abbiamo eseguito.

# what address does the world see?
curl -s https://api.ipify.org

# how is it classified?
curl -s "http://ip-api.com/json/<that-address>?fields=isp,as,hosting,proxy,mobile"

# what does reverse DNS say about it?
dig +short -x <that-address>

Esegui gli stessi tre comandi da un runner di CI in cloud e confronta. Il flag hosting e lo schema del DNS inverso di solito bastano a spiegare un test che fallisce solo in CI.

I limiti, detti onestamente

• Nessun IPv4 pubblico statico o dedicato. L’indirizzo è assegnato dalla linea in fibra business e può cambiare. Se ti serve un indirizzo fisso in una allow list, questo è il prodotto sbagliato.
• Nessuna porta in ingresso. Raggiungi il Mac tramite una rete Tailscale privata, oppure dal desktop nel browser. Niente è esposto su internet.
• Una sola sede. Non puoi scegliere una città o un paese.
• Solo servizi agli sviluppatori. La politica di uso accettabile copre CI, build, test e strumenti per sviluppatori, compresi gli agenti di coding, sul tuo software. Non copre lo scraping su larga scala né l’aggiramento dei termini di altri servizi. Un indirizzo di rete reale non è un invito a provarci.

A cosa serve

• QA su servizi reali che valutano il traffico cloud in modo diverso.
• Simulatori e dispositivi di test che parlano con API di produzione durante la CI.
• Pipeline di build per app il cui backend blocca gli intervalli cloud.
• Agenti di coding che leggono la documentazione e accedono agli strumenti per sviluppatori senza sbattere contro i blocchi anti-bot.

Prima descrivevamo la sede con cautela. Ora la descriviamo con precisione, perché per i clienti a cui è adatta la precisione è proprio il punto di forza.