Dokumentacja komponentu serwera http, szczególnie dla węzła, w przypadku połączenia ze zdarzeniem mówi:
[Wyzwolony] po ustanowieniu nowego strumienia TCP. [Gniazdo] jest obiektem typu net.Socket. Zwykle użytkownicy nie będą chcieli uzyskać dostępu do tego wydarzenia. W szczególności gniazdo nie będzie emitować czytelnych zdarzeń ze względu na sposób, w jaki parser protokołu łączy się z gniazdem. Dostęp do gniazda można również uzyskać pod adresem request.connection
.
Oznacza request.connection
to , że jest to gniazdo i zgodnie z dokumentacją rzeczywiście istnieje atrybut socket.remoteAddress, który zgodnie z dokumentacją to:
Ciąg reprezentujący zdalny adres IP. Na przykład „74 .125.127.100” lub „2001: 4860: a005 :: 68”.
W trybie express obiekt żądania jest również instancją obiektu żądania Node http, więc to podejście powinno nadal działać.
Jednak w Express.js żądanie ma już dwa atrybuty: req.ip i req.ips
req.ip
Zwróć adres zdalny lub gdy „zaufane proxy” jest włączone - adres nadrzędny.
req.ips
Gdy „proxy proxy” jest true
, przeanalizuj listę adresów IP „X-Forwarded-For” i zwróć tablicę, w przeciwnym razie zwracana jest pusta tablica. Na przykład, jeśli wartością byłoby „klient, proxy1, proxy2”, otrzymalibyście tablicę [„klient”, „proxy1”, „proxy2”], gdzie „proxy2” jest najdalszym strumieniem zstępującym.
Warto wspomnieć, że moim zdaniem Express req.ip
jest lepszym podejściem niż req.connection.remoteAddress
od tamtej poryreq.ip
zawiera rzeczywisty adres IP klienta (pod warunkiem, że zaufane proxy jest włączone w trybie ekspresowym), podczas gdy drugi może zawierać adres IP proxy (jeśli istnieje jeden).
Z tego powodu obecnie akceptowana odpowiedź sugeruje:
var ip = req.headers['x-forwarded-for'] ||
req.connection.remoteAddress;
req.headers['x-forwarded-for']
Będzie równowartość wyraźnej req.ip
.