# Все подключения теперь показывают 127.0.0.1

**URL:** https://f.docs.rw/t/topic/349
**Category:** Баг-репорты
**Created:** 2026-07-03T04:52:57Z
**Posts:** 4

## Post 1 by @Davletchin — 2026-07-03T04:52:57Z

## Суть проблемы

В бандл Remnanode недавно обновили Xray-core с **v26.3.27** (Node 2.7.0) до **v26.6.27** (текущий релиз). В этой версии Xray-core есть регрессия, которая ломает определение IP клиента для gRPC-инбаундов за Nginx-реверс-прокси, передающим заголовок `X-Real-IP` (это официально задокументированный способ — см. [gRPC | Project X](https://xtls.github.io/en/config/transports/grpc.html) ). Все подключения теперь показывают `127.0.0.1` как исходный IP вместо реального адреса клиента.

Баг-репорт в апстрим уже заведён: XTLS/Xray-core#6423

Это не баг в самом коде Remnanode — проблема чисто в бандлящемся бинарнике Xray-core, — но поскольку функция отслеживания IP / «online users» в Remnanode опирается на то, что Xray-core корректно репортит source IP, это напрямую ломает эту функциональность у всех, кто использует gRPC за реверс-прокси (довольно распространённая схема для маскировки/opsec).

## Как воспроизвести

1. Запустить Remnanode 2.7.0 (Xray-core v26.3.27) за Nginx (gRPC + заголовок `X-Real-IP`) → IP клиентов отслеживаются корректно.
2. Обновить Remnanode до текущего релиза (Xray-core v26.6.27), конфигурация во всём остальном идентична → все пользователи отображаются как подключившиеся с `127.0.0.1`.
3. Откатить обратно на Remnanode 2.7.0 → корректные IP возвращаются сразу же.

## Предложение / просьба

- Рассмотреть возможность временно закрепить (запинить) Xray-core на заведомо рабочей версии, пока апстрим-регрессия не будет исправлена (отслеживается в XTLS/Xray-core#6423), либо
- Добавить простой способ переопределить версию бандлящегося Xray-core через переменную окружения / volume-mount, чтобы операторам не приходилось откатывать весь Node целиком (и терять более новые фичи, совместимые с актуальной Panel) только чтобы обойти регрессию в апстриме.

## Окружение

- Remnanode: официальный Docker-образ `remnawave/node`
- Цепочка реверс-прокси: клиент → HAProxy (PROXY protocol) → Nginx (gRPC, `X-Real-IP`) → Remnanode
- Подтверждено, что регрессия изолирована именно в версии бинарника Xray-core, а не в конфигурации реверс-прокси (конфиг nginx/haproxy идентичен в обоих тестах).

---

## Post 2 by @UnderGut — 2026-07-03T05:22:16Z

Ты можешь просто примонтировать нужную версию ядра к ноде. Это уже давно реализуемо и покрывает твои запросы

---

## Post 3 by @remnawave — 2026-07-03T11:50:15Z

> <https://github.com/XTLS/Xray-core/issues/6382#issuecomment-4813562946>
>
> ### Integrity requirements
> 
> - [x] I have read all the comments in the issue temp…late and ensured that this issue meet the requirements.
> - [x] I confirm that I have read the documentation, understand the meaning of all the configuration items I wrote, and did not pile up seemingly useful options or default values.
> - [x] I provided the complete config and logs, rather than just providing the truncated parts based on my own judgment.
> - [x] I searched issues and did not find any similar issues.
> - [x] The problem can be successfully reproduced in the latest Release
> 
> ### Description
> 
> There is a functional limitation in how Xray-core handles upstream client real IPs when deployed behind enterprise HTTP-based CDNs other than Cloudflare (specifically Fastly, AWS CloudFront, or GCore) utilizing the `xhttp` transport protocol.
> 
> While Cloudflare's `CF-Connecting-IP` works smoothly due to embedded logic or specific presets, other CDNs rely strictly on injecting traditional headers like `X-Real-IP` or `X-Forwarded-For`. 
> 
> Currently, when using `xhttp` behind Fastly, Xray-core falls back to recording the CDN's edge server IPs instead of the downstream client's real IP. This completely breaks internal IP limiting (`IP Limit`) features unless users "trick" the core by applying Cloudflare-specific presets to non-Cloudflare traffic or chain an external reverse proxy (like Nginx) using the PROXY protocol. Xray-core should have a transport-agnostic, explicit option to parse custom HTTP real-IP headers natively.
> 
> 
> # Fastly 传递真实 IP 设置指南 (X-Real-IP)
> 
> ### 🛠 步骤：
> 
> 1. 登录 Fastly 控制台 -> 点击 **Services** -> 选择你的服务 -> 点击右上角 **Edit configuration** 创建新版本。
> 2. 在左侧菜单点击 **Headers** -> 点击 **Create Header** 。
> 3. 按照以下参数填写表单：
> * **Name:** `Add-Real-IP` (或任意名称)
> * **Type:** `Request`
> * **Action:** `Set`
> * **Destination:** `http.X-Real-IP`
> * **Source:** `client.ip`
> 4. 点击 **Create** 保存，最后点击右上角 **Activate** 生效。
> 
> ### Reproduction Method
> 
> ### Description
> 
> There is an inconsistency in how `Xray-core` processes upstream client real IPs when deployed behind HTTP-based CDNs other than Cloudflare (specifically **Fastly** , AWS CloudFront, or GCore) utilizing the `xhttp` transport protocol. 
> 
> While Cloudflare's `CF-Connecting-IP` is natively understood or easily mapped via preset configurations, other CDNs rely strictly on injecting traditional headers like `X-Real-IP` or `X-Forwarded-For`. 
> 
> Currently, to make the internal IP limiter (`IP Limit`) work and capture the correct client IP under Fastly, downstream panel developers and users are forced to trick Xray by setting the inbound proxy presets to `Cloudflare` while mapping custom `sockopt` fields, which is structurally redundant and breaks if the upstream CDN signature diverges.
> 
> ### Expected Behavior
> Xray-core should offer a reliable, transport-agnostic, and explicit mechanism within `streamSettings` or `sockopt` to explicitly trust and parse arbitrary/custom HTTP real-IP headers (e.g., `X-Real-IP`, `X-Forwarded-For`, `Fastly-Client-IP`) for all HTTP-based protocols (like `xhttp`), ensuring the core accurately tracks the downstream client's real IP for connection limiting and routing purposes, independent of the Cloudflare-specific codebase ecosystem.
> 
> ### Actual Behavior
> When traffic passes through Fastly via `xhttp`, Xray-core defaults to recording the CDN's edge server IPs instead of parsing the injected `X-Real-IP` header properly, unless obscure fallback configurations or third-party reverse proxies (like Nginx with PROXY protocol) are chained in front of the inbound. This breaks strict IP limiting functionalities out of the box.
> 
> ### Proposed Solution / Feature Enhancement
> Extend the `sockopt` configuration or introduce a generic `realIpSettings` block inside `inboundDetour` for HTTP-based networks (`xhttp`, `http`, `websocket`) that explicitly allows specifying the trusted header key:
> 
> ```json
> "sockopt": {
> "acceptProxyProtocol": false,
> "trustedRealIpHeader": "X-Real-IP" // Or "X-Forwarded-For"
> }
> 
> ### Client config
> 
> None
> 
> ### Server config
> 
> None
> 
> ### Client log
> 
> None
> 
> ### Server log
> 
> None

---

## Post 4 by @remnawave — 2026-07-03T11:50:43Z

Версия Remnawave Node v2.8.0 будет работать только с 26.6.27 и выше. Старое ядро не поддерживается.

---

## Post 5 by @system — 2026-07-05T11:51:08Z

Эта тема была автоматически закрыта через 2 дня после последнего ответа. В ней больше нельзя отвечать.