ADB via internet su Android: configurazioni sicure con e senza root

Non serve il root per raggiungere l’ADB del tuo telefono da un altro paese. Servono un modo per attivare ADB via TCP e un percorso privato tra il computer e il telefono. Il root cambia solo la prima parte: permette al telefono di attivare ADB da solo e di mantenerlo attivo dopo un riavvio, senza cavo. Tutto il resto di questa guida funziona allo stesso modo su un telefono stock.

I due modi in cui si sbaglia sono gli stessi con o senza root: si segue un tutorial che inoltra la porta 5555 sul router di casa, oppure ci si fida di una connessione che funziona sul Wi-Fi e fallisce in silenzio con i dati mobili.

Questa guida riguarda il telefono di tua proprietà: un dispositivo di scorta su cui esegui i test, un telefono a casa che vuoi raggiungere mentre sei in viaggio, una piccola device farm. Non spiega come raggiungere il dispositivo di qualcun altro. Illustra come funziona ADB da remoto, come attivarlo con e senza root e tre metodi di connessione che non espongono mai ADB su internet. I passaggi che richiedono il root sono contrassegnati con Solo root.

In breve: attiva ADB via TCP sul telefono, rendilo raggiungibile solo tramite un percorso privato e cifrato e usa quel percorso dal computer. Tailscale è la via più semplice. Un tunnel SSH inverso tramite un piccolo server tuo è la più universale. Il semplice inoltro della porta 5555 è l’unica configurazione da evitare.

Con o senza root: cosa cambia

La differenza pratica riguarda l’affidabilità, non le possibilità. Un telefono stock funziona bene da remoto finché non si riavvia, poi resta irraggiungibile finché qualcuno con il telefono e un computer non lo ripristina. Per un telefono in un’altra città è questo il motivo per rootarlo. Per un telefono che puoi raggiungere di persona, o per un test di breve durata, non serve.

Cosa protegge davvero ADB e cosa no

Molti consigli sull’ADB remoto dicono che ADB via rete è “senza cifratura e senza autenticazione”. È vero solo a metà, e la metà sbagliata conta per come imposti tutto.

L’ADB di rete classico, la modalità adb tcpip 5555, è non cifrato. Le note di progettazione di ADB in Android descrivono il trasporto legacy come pacchetti in chiaro, mentre la modalità Wi-Fi introdotta in Android 11 avvolge la sessione in TLS.fonte 2 Chiunque possa osservare il percorso tra te e il telefono può leggere ciò che invii.

L’autenticazione è un’altra faccenda. Su una normale build di produzione, ADB chiede comunque al telefono di approvare la chiave RSA del tuo computer. Alla prima connessione adb devices mostra unauthorized e il telefono visualizza una finestra: “Allow USB debugging?” con l’impronta della chiave. La documentazione di Android afferma che i comandi adb non possono essere eseguiti finché non sblocchi il dispositivo e confermi quella finestra.fonte 1 Le chiavi che approvi vengono salvate sul telefono, e spuntare “Always allow from this computer” è ciò che rende silenziose le connessioni successive.

Ne derivano due conseguenze pratiche. Primo: su un telefono stock una porta esposta non è una porta aperta a un estraneo, ma lo è per chiunque ottenga una chiave di cui il telefono già si fida, ed è un varco totale su qualsiasi dispositivo con l’autenticazione disattivata. I malware diffusi tramite la porta 5555 hanno trovato soprattutto quei dispositivi: TV box, proiettori, build per sviluppatori e telefoni su cui qualcuno ha disattivato il flag secure. Secondo: la primissima connessione da un computer nuovo richiede una mano sullo schermo. Pianifica di autorizzare la tua chiave quando hai il telefono a portata di mano, con un cavo USB o sul Wi-Fi di casa, e spunta la casella che la ricorda.

Perché il debug wireless è lo strumento sbagliato per l’accesso remoto non presidiato

Il debug wireless sembra la scelta più sicura, e per un portatile sul Wi-Fi di casa lo è. Per l’accesso remoto ti rema contro. La porta di connessione è casuale e cambia quando disattivi e riattivi la funzione, il rilevamento si basa su mDNS, che non attraversa una VPN, e le versioni più recenti di Android lo disattivano da sole. Android 17 con ADB 37 introduce “ADB Wi-Fi 2.0”, che disattiva il debug wireless sulle reti che non hai contrassegnato come attendibili e si riconnette in automatico su quelle che hai contrassegnato.fonte 4 Un comportamento ottimo per la scrivania di uno sviluppatore, ma del tutto sbagliato per un telefono che devi poter raggiungere da un altro paese.

Se vuoi i dettagli su questa funzione, la nostra guida all’ADB wireless su Android 17 spiega associazione, reti attendibili e il problema del dispositivo associato ma offline. Per l’uso remoto, la base migliore è la porta TCP fissa, che puoi attivare con o senza root e poi proteggere con qualcosa di più robusto della porta stessa.

Passaggio 1: attiva ADB via TCP

Scegli la parte adatta al tuo telefono. Entrambe portano allo stesso stato: il daemon ADB del telefono è in ascolto sulla porta 5555, e il Passaggio 2 la protegge.

Senza root

Su qualsiasi telefono Android, abilita le opzioni sviluppatore e il debug USB, collega il telefono a un computer con un cavo, approva la chiave quando il telefono te lo chiede ed esegui:

adb tcpip 5555

Scollega il cavo. Il telefono ora accetta ADB via rete sulla porta 5555 fino al riavvio. Su alcune build l’impostazione si azzera anche quando attivi o disattivi il debug USB, quindi se la porta smette di rispondere esegui di nuovo il comando. Poiché l’impostazione si perde al riavvio, un telefono senza root richiede una persona con un cavo dopo ogni riavvio. Va bene per un telefono che controlli tu, ma non per uno che non puoi raggiungere.

Su Android 11 e successivi c’è un modo per eseguire lo stesso passaggio senza alcun computer, molto usato dalla community, anche se non lo abbiamo provato su ogni dispositivo. Attivi il debug wireless, installi Termux e il suo pacchetto di strumenti Android, associ Termux al telefono stesso con il codice di associazione, ti connetti all’indirizzo del telefono ed esegui da lì adb tcpip 5555. In quel momento il telefono deve essere connesso al Wi-Fi. Consideralo un ripiego per il giorno in cui hai dimenticato il cavo e cerca una guida aggiornata a Termux per i comandi esatti, perché cambiano con il pacchetto e con la versione di Android.

Con root (solo root)

Su un telefono con root, apri un’app terminale come Termux e ottieni una shell root. La proprietà che controlla la porta viene letta dal daemon ADB stesso, e il codice sorgente del daemon controlla service.adb.listen_addrs, poi service.adb.tcp.port, poi persist.adb.tcp.port.fonte 3

su
setprop service.adb.tcp.port 5555
stop adbd
start adbd

Riavviare il daemon interrompe qualsiasi sessione di debug USB aperta, quindi eseguilo dal telefono e non da un PC collegato via cavo. Verifica che sia in ascolto:

getprop service.adb.tcp.port
ss -ltn | grep 5555

Alcune build di Android non includono ss; su altre funziona netstat -ltn. Se non c’è nessuno dei due, la prova vera è il test di connessione dal computer nel Passaggio 2.

La proprietà service. si perde al riavvio del telefono. Un telefono che non riesci a raggiungere dopo un’interruzione di corrente non è un telefono remoto, quindi rendi l’impostazione persistente. Ci sono due modi, che si combinano bene. Il primo è la proprietà persistente:

setprop persist.adb.tcp.port 5555

Il secondo è uno script di avvio. Con Magisk, uno script shell salvato in /data/adb/service.d/ e reso eseguibile viene eseguito verso la fine dell’avvio; KernelSU e APatch usano invece un piccolo modulo con un file service.sh. Consulta la documentazione del tuo gestore root per la posizione esatta, perché cambia tra strumenti e versioni.

#!/system/bin/sh
until [ "$(getprop sys.boot_completed)" = "1" ]; do sleep 5; done
setprop service.adb.tcp.port 5555
stop adbd
start adbd

Riavvia una volta e prova. I produttori Android trattano queste proprietà in modo diverso e alcune ROM le ignorano o le azzerano. Su Android 11 e successivi, una regola SELinux ha impedito in passato ad ADB di impostare la proprietà della porta su alcune build, ed è stata poi allentata.fonte 5 Se sul tuo telefono non sopravvive al riavvio, la soluzione è lo script di avvio; se il daemon non va mai in ascolto, la tua ROM potrebbe bloccare la proprietà. In quel caso il ripiego è una sessione USB con adb tcpip 5555 dopo ogni avvio, cioè il metodo senza root descritto sopra.

Per disattivarlo di nuovo, con root:

setprop service.adb.tcp.port -1
setprop persist.adb.tcp.port ""
stop adbd
start adbd

Senza root, ottieni lo stesso risultato disattivando il debug USB nelle opzioni sviluppatore o riavviando il telefono.

A questo punto il telefono è in ascolto su ogni interfaccia di rete che ha. Va bene finché le uniche cose in grado di raggiungere quelle interfacce siete tu e la tua rete attendibile, ed è proprio il compito del passaggio successivo.

Passaggio 2: scegli un percorso privato verso il telefono

Ogni metodo qui sotto funziona con o senza root. Tutti hanno lo stesso obiettivo: dare al tuo computer una via cifrata e autenticata verso la porta 5555 del telefono, senza accettare connessioni in ingresso da internet. Questa seconda parte conta più di quanto sembri. La maggior parte dei telefoni su rete mobile si trova dietro un CGNAT dell’operatore, quindi un inoltro sul router non li raggiungerebbe nemmeno volendo.

Metodo A: Tailscale

Tailscale crea una rete privata tra i tuoi dispositivi e attraversa il NAT al posto tuo, ed è per questo che funziona da un telefono con dati mobili. Installalo sul telefono e sul computer e accedi con lo stesso account. Ogni dispositivo riceve un indirizzo stabile che inizia con 100.; l’indirizzo del telefono si vede nell’app e nella console di amministrazione.

Dal computer:

adb connect 100.x.y.z:5555
adb devices

La prima volta il telefono ti chiede di approvare la chiave, ed è per questo che conviene farlo una volta con il telefono in mano. L’app Tailscale non richiede il root. Dopo, adb shell, adb push, adb logcat e scrcpy funzionano come se il telefono fosse sulla tua scrivania.

Tre impostazioni rendono tutto questo non solo comodo, ma affidabile. Prima: per impostazione predefinita Tailscale permette a ogni dispositivo della rete di raggiungere tutti gli altri, ed è nel file delle policy che si restringe l’accesso. Una regola che permette solo al tuo account di raggiungere il telefono con tag sulla porta 5555 appare così nella policy di accesso:fonte 6

{ "action": "accept", "src": ["you@example.com"], "dst": ["tag:phone:5555"] }

Seconda: disattiva la scadenza della chiave per il telefono nella console di amministrazione, altrimenti uscirà dalla tua rete alla scadenza e da lontano non potrai rimetterlo. Terza: concedi all’app Tailscale l’uso illimitato della batteria nelle impostazioni di Android. Gli utenti segnalano che con una gestione energetica aggressiva l’app viene arrestata o si disconnette ogni pochi minuti, e una disconnessione a metà di un trasferimento è il sintomo tipico.fonte 8

Vale la pena conoscere due limiti. Il server SSH integrato di Tailscale non gira su Android, perché per quella funzione la piattaforma è solo client: usa direttamente la porta ADB oppure il tunnel SSH qui sotto se ti serve una shell senza ADB.fonte 7 E non usare Tailscale Funnel per questo scopo. Serve a pubblicare servizi web su internet, cioè il contrario di ciò che vuoi ottenere.

Metodo B: tunnel SSH inverso tramite un tuo server

Questo metodo non richiede nulla da terzi. Affitti il più piccolo server virtuale che trovi: il telefono si connette in uscita verso di esso e mantiene aperta la connessione. Il tuo computer si connette allo stesso server e raggiunge il telefono passando da lì. Poiché è il telefono a chiamare, funziona dietro CGNAT e sul Wi-Fi degli hotel.

Sul telefono, in Termux, che non richiede il root, installa il client SSH e crea una chiave:

pkg install openssh autossh
ssh-keygen -t ed25519

Sul server, crea un utente dedicato e aggiungi la chiave pubblica del telefono al suo file authorized_keys, con restrizioni tali che la chiave possa solo aprire l’unica porta in ascolto sull’interfaccia di loopback:

restrict,port-forwarding,permitlisten="127.0.0.1:15555" ssh-ed25519 AAAA... phone

Poi, sul telefono, mantieni aperto il tunnel. Le opzioni qui sotto fanno fallire la connessione in modo evidente se la porta non può essere associata e le impediscono di restare appesa in silenzio su una rete morta:

ssh -N -R 127.0.0.1:15555:127.0.0.1:5555 \
  -o ServerAliveInterval=30 -o ServerAliveCountMax=3 \
  -o ExitOnForwardFailure=yes tunnel@your-server.example

autossh può supervisionare quel comando e riavviarlo, e il componente aggiuntivo Termux:Boot può avviarlo dopo un riavvio, con termux-wake-lock per tenere sveglia la CPU finché il tunnel è attivo. Imposta su illimitato anche l’uso della batteria per Termux. Questi elementi dipendono dalla tua versione di Android e da quanto il tuo produttore chiude con decisione le app in background, quindi prova con lo schermo spento per un’ora prima di affidarti a questa configurazione.

Dal tuo computer, inoltra una porta locale al tunnel e connettiti attraverso di esso:

ssh -N -L 5556:127.0.0.1:15555 you@your-server.example
adb connect 127.0.0.1:5556

Fai caso alla porta locale 5556. Il tuo server ADB occupa spesso già la 5555 e un conflitto su quella porta produce errori poco chiari. L’inoltro remoto è associato all’indirizzo di loopback del server, quindi nulla su internet può raggiungerlo direttamente, e il comportamento predefinito di OpenSSH per gli inoltri remoti rifiuta già di associarsi a un’interfaccia pubblica, a meno che tu non abbia modificato GatewayPorts.

Sul server usa solo accessi con chiave e tieni disattivata la password per quell’utente. Un tunnel inverso con accesso tramite password su un server SSH esposto a internet non è molto più sicuro dell’inoltro di porta che sostituisce.

Metodo C: WireGuard sul tuo server

WireGuard ti dà lo stesso risultato di Tailscale, con ogni ingranaggio sotto il tuo controllo. Esegui un endpoint WireGuard su un server con indirizzo pubblico, aggiungi telefono e computer come peer e imposta PersistentKeepalive = 25 sul lato del telefono, così le reti mobili mantengono attiva la mappatura NAT. L’app WireGuard di Android, che non richiede il root, passa tra Wi-Fi e LTE e può funzionare come VPN sempre attiva. Dal computer ti connetti poi all’indirizzo WireGuard del telefono sulla porta 5555, esattamente come con Tailscale. È la scelta giusta quando vuoi una configurazione fissa e permanente e non ti pesa gestire il server.

Una nota su un’alternativa diffusa: Cloudflare Tunnel è documentato per SSH, ma non abbiamo verificato una configurazione pulita per il traffico ADB grezzo, quindi qui non lo consigliamo.

La configurazione da evitare: inoltrare la porta 5555 sul router

È allettante inoltrare la porta esterna 5555, o una porta personalizzata “furba”, verso il telefono e considerare chiusa la questione. Non farlo. Invia ADB non cifrato attraverso internet, dipende interamente da una sola richiesta di chiave e si annuncia agli scanner che cercano esattamente questo.

Non è teoria. Nel 2020 i ricercatori di Keysight, analizzando la botnet Trinity, hanno segnalato circa 40.000 dispositivi ADB esposti e visibili su Shodan, circa un quarto dei quali telefoni, con il malware che vi si connetteva usando adb connect stesso.fonte 9 Una botnet concorrente, Fbot, ha rimosso Trinity dai dispositivi infetti, e Trinity è tornata nel giro di poche ore. A febbraio 2021 la botnet Matryosh, basata sul codice di Mirai, si è diffusa sulla stessa porta.fonte 10 Cambiare il numero della porta esterna non serve a nulla, perché gli scanner provano ogni porta.

Alcune guide scendono a compromessi inoltrando invece la porta SSH di un server Termux. È meglio che inoltrare ADB, ma pubblica comunque un servizio SSH sul tuo IP di casa, e un accesso Termux con password è una pessima idea da lasciare esposta su internet. Un tunnel inverso o una rete overlay ti dà lo stesso risultato senza alcuna porta in ingresso.

Checklist di sicurezza

Autorizza solo i computer che usi davvero e revoca quelli vecchi. Nelle opzioni sviluppatore, “Revoke USB debugging authorizations” cancella ogni chiave salvata, una buona abitudine prima di consegnare il telefono a qualcun altro. Tieni disattivato il debug ADB su qualsiasi telefono che non ne ha bisogno e considera la porta aperta nel Passaggio 1 parte della stessa decisione. Non spuntare “Always allow” su un computer condiviso o pubblico.

Una sessione ADB autorizzata vede ciò che vede l’utente shell, che è già molto: app installate, file che puoi leggere, schermo e input. Solo root: su un telefono con root, adb shell su può arrivare molto più in là se il tuo gestore root lo concede alla shell, quindi imposta il gestore in modo che chieda conferma per la shell invece di consentirlo in silenzio.

Solo root: alcune persone aggiungono una regola firewall sul telefono perché la porta 5555 risponda solo sull’interfaccia VPN. L’idea è valida, ma non abbiamo potuto confermare che sia affidabile su Android. Il daemon di rete del sistema può riordinare o svuotare le regole quando la rete cambia, e l’app Tailscale stock non crea un’interfaccia tailscale0 su cui basare la regola. Se la provi, riapplica la regola dal tuo script di avvio e prova da un dispositivo che non sia sulla VPN.

Lavorare con una connessione lenta

Un telefono dietro un tunnel sembra più lento di uno sulla tua scrivania, e di solito la soluzione è chiedere meno. Per lo screen mirroring con scrcpy, abbassa risoluzione e bitrate, per esempio scrcpy -s 100.x.y.z:5555 -m 1280 -b 4M; i nomi dei flag cambiano leggermente tra le versioni, quindi controlla scrcpy --help. scrcpy può anche attivare per te la modalità TCP con --tcpip, e la sua documentazione consiglia di disconnettersi al termine.fonte 11 Un percorso Tailscale diretto è più veloce di uno instradato dai server del produttore, e lo stato della connessione nell’app ti dice quale hai.

Quando è connesso più di un dispositivo, indica ad ADB quale intendi con adb -s 100.x.y.z:5555 ..., oppure usa -d per il dispositivo USB e -e per un emulatore. I trasferimenti di file e adb logcat sono le attività che tollerano meglio la latenza.

Risoluzione dei problemi

Con root puoi verificare cosa sta usando davvero il telefono eseguendo getprop service.adb.tcp.port e getprop persist.adb.tcp.port in una shell root. Senza root, il test è adb connect dal computer. Se il telefono usa anche il debug wireless, ricorda che la sua porta TLS casuale è salvata a parte, quindi una connessione wireless funzionante non dice nulla sulla porta fissa.

Domande frequenti

Serve il root? No. Senza root attivi ADB via TCP una volta tramite USB e usi Tailscale, un tunnel inverso o WireGuard esattamente come descritto. Il prezzo è che l’impostazione si perde a ogni riavvio, quindi qualcuno deve ricollegare un cavo. Il root elimina quel passaggio e aggiunge le opzioni firewall e su, e nient’altro in questa guida dipende dal root.

Funziona con i dati mobili? Sì, perché Tailscale, WireGuard e un tunnel inverso si connettono tutti in uscita dal telefono. L’inoltro di porta sul router è il metodo che lì fallisce.

È sicuro lasciarlo sempre attivo? È sicuro quanto il percorso che lo protegge. Dietro una rete overlay con una policy di accesso, l’esposizione è ridotta. Lascialo attivo solo se lo userai davvero e disattivalo quando non ti serve.

Qualcuno può abusarne senza la richiesta della chiave? Su una build normale, un computer nuovo deve essere approvato sul telefono. Su qualsiasi build in cui l’autenticazione del debug è disattivata, chiunque può connettersi senza, ed è per questo che non dovresti mai esporre quella porta a internet, a prescindere dalla build.

Perché non usare semplicemente un’app di desktop remoto? Per usare lo schermo va bene, e un’app di condivisione dello schermo non richiede alcun root. ADB è lo strumento giusto quando ti servono comandi shell, installazioni, trasferimenti di file o log a distanza.

Prima di affidarti a questa configurazione

Prova tutto con il telefono sui dati mobili e il computer su una rete diversa. Riavvia il telefono e controlla cosa torna da solo: su un telefono con root la configurazione dovrebbe ripristinarsi da sola, su uno senza root devi sapere esattamente cosa rifare. Prova anche con lo schermo spento per un po’. Se dopo uno qualsiasi di questi test non riesci a raggiungere il telefono, hai trovato il problema quando è ancora economico da risolvere.

Se stai ancora scegliendo un telefono per progetti come questo e ne vuoi uno che puoi rootare, il nostro catalogo dei telefoni rootabili mostra quali modelli si sbloccano senza problemi, e la guida ai moduli Magisk copre la parte dei moduli dello script di avvio che richiede il root. Per una shell Linux che non dipende dal root, vedi Terminale Linux di Android vs Termux.

Fonti e ambito

Questa guida è stata redatta a ottobre 2026 a partire dalla documentazione e dal codice sorgente di Android, oltre che da pubblicazioni dei produttori e della ricerca sulla sicurezza. Non abbiamo provato ogni versione di Android e ogni ROM. Il comportamento delle proprietà, gli script di avvio, il trucco per attivarlo dal telefono, l’approccio firewall e il comportamento della batteria di Termux variano da dispositivo a dispositivo, quindi verifica ciascuno sul tuo telefono prima di dipenderne.

• Fonte 1: Android Developers, Android Debug Bridge (adb) Apri la fonte
• Fonte 2: Android Open Source Project, note di progettazione di ADB Wi-Fi: il TCP legacy non è cifrato, la modalità Wi-Fi usa TLS Apri la fonte
• Fonte 3: Android Open Source Project, adbd main.cpp, selezione della porta dalle proprietà Apri la fonte
• Fonte 4: Android Developers Blog, debug wireless e ADB Wi-Fi 2.0 Apri la fonte
• Fonte 5: OmniROM, modifica della policy SELinux per le proprietà di adbd Apri la fonte
• Fonte 6: Tailscale, Access control lists Apri la fonte
• Fonte 7: Tailscale, supporto di Tailscale SSH per piattaforma Apri la fonte
• Fonte 8: Forum della community Tailscale, disconnessioni di Android e uso della batteria Apri la fonte
• Fonte 9: Keysight, malware TrinityP2P tramite ADB Apri la fonte
• Fonte 10: The Hacker News, botnet DDoS Matryosh, febbraio 2021 Apri la fonte
• Fonte 11: Documentazione di scrcpy, Connection Apri la fonte