Soprattutto per il nodo, la documentazione per il componente server http, sotto la connessione dell'evento dice:
[Triggered] quando viene stabilito un nuovo flusso TCP. [Il] socket è un oggetto di tipo net.Socket. Di solito gli utenti non vorranno accedere a questo evento. In particolare, il socket non emetterà eventi leggibili a causa di come il parser di protocollo si collega al socket. È possibile accedere al socket anche all'indirizzo request.connection
.
Quindi, ciò significa che request.connection
è un socket e secondo la documentazione esiste effettivamente un attributo socket.remoteAddress che secondo la documentazione è:
La rappresentazione in formato stringa dell'indirizzo IP remoto. Ad esempio, '74 .125.127.100 'o' 2001: 4860: a005 :: 68 '.
Sotto express, l'oggetto richiesta è anche un'istanza dell'oggetto richiesta http Node, quindi questo approccio dovrebbe ancora funzionare.
Tuttavia, in Express.js la richiesta ha già due attributi: req.ip e req.ips
req.ip
Restituisce l'indirizzo remoto o quando è abilitato "proxy di fiducia" - l'indirizzo upstream.
req.ips
Quando "proxy di fiducia" è true
, analizzare l'elenco di indirizzi IP "X-Forwarded-For" e restituire un array, altrimenti viene restituito un array vuoto. Ad esempio, se il valore fosse "client, proxy1, proxy2" si riceverà l'array ["client", "proxy1", "proxy2"] dove "proxy2" è il downstream più lontano.
Vale la pena ricordare che, secondo la mia comprensione, Express req.ip
è un approccio migliore rispetto a req.connection.remoteAddress
, poiché req.ip
contiene l'ip client effettivo (a condizione che il proxy trusted sia abilitato in express), mentre l'altro può contenere l'indirizzo IP del proxy (se esiste uno).
Questo è il motivo per cui la risposta attualmente accettata suggerisce:
var ip = req.headers['x-forwarded-for'] ||
req.connection.remoteAddress;
Il req.headers['x-forwarded-for']
sarà l'equivalente di espresso req.ip
.