Use routeRules-proxy behind cloudflare

[ahoiroman]

Hi there,

well, it's me again, asking stupid questions about the routeRules-proxy combined with nuxt-auth-sanctum 🙈

Abstract

I am using sanctum in my nuxt project using routeRules-proxy to access my Laravel backend.
That nuxt project is behind Cloudflare Proxy and I am trying to get the user's IP on the backend, which currently does not work.

The current setup

User Request -> Cloudflare Proxy -> Load Balancer -> internal Network

Inside the internal network I got two virtual machines that are hosting:

• webserver1: Nuxt
• webserver2: Laravel

While Nuxt is accessible via Cloudflare, the Laravel-API is only reachable from inside the private network.

So if a user hits example.com, the request chain is:

Cloudflare Proxy -> Load Balancer -> webserver1

Now to make things a little more complicated, I need to use nitro proxy:

routeRules: {
    '/backend/**': {
      proxy: {
        to: `${process.env.NUXT_BACKEND_URL}/**`,
        headers: { accept: 'application/json' }
      }
    },
},

and the sanctum base URL is set to that backend:

NUXT_PUBLIC_SANCTUM_BASE_URL=https://example.com/backend

This works.

The problem

But there is one little problem: The client IP gets lost on the Laravel api.

So if I log request()->ip(), I get 10.0.1.1, which is the internal IP of the load balancer.

If I refresh the page, the following log appears on the laravel's webserver:

{
  "level": "info",
  "ts": 1748417160.4333572,
  "logger": "http.log.access.log0",
  "msg": "handled request",
  "request": {
    "remote_ip": "10.0.1.1",
    "remote_port": "50144",
    "client_ip": "10.0.1.1",
    "proto": "HTTP/1.1",
    "method": "GET",
    "host": "api.example.com",
    "uri": "/api/v1/user/current",
    "headers": {
      "User-Agent": [
        "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Safari/537.36"
      ],
      "Accept": [
        "application/json"
      ],
      "Cf-Ipcountry": [
        "DE"
      ],
      "Via": [
        "2.0 Caddy, 1.1 Caddy",
        "1.1 Caddy"
      ],
      "Origin": [
        "http://example.com"
      ],
      "Accept-Language": [
        "*"
      ],
      "Cookie": [
        "REDACTED"
      ],
      "X-Forwarded-For": [
        "10.0.2.1"
      ],
      "X-Forwarded-Proto": [
        "https"
      ],
      "Accept-Encoding": [
        "br, gzip, deflate"
      ],
      "Cdn-Loop": [
        "cloudflare; loops=1"
      ],
      "Cf-Visitor": [
        "{\"scheme\":\"https\"}"
      ],
      "Cf-Connecting-Ip": [
        "public.ip.of.webservers.nat.gateway"
      ],
      "Referer": [
        "http://example.com"
      ],
      "X-Forwarded-Host": [
        "api.example.com"
      ],
      "Sec-Fetch-Mode": [
        "cors"
      ],
      "Cf-Ray": [
        "946c0573cf8839d0-FRA"
      ]
    }
  },
  "bytes_read": 0,
  "user_id": "",
  "duration": 0.08878313,
  "size": 170,
  "status": 200,
  "resp_headers": {
    "Date": [
      "Wed, 28 May 2025 07:26:00 GMT"
    ],
    "Content-Type": [
      "application/json"
    ],
    "Access-Control-Allow-Origin": [
      "https://example.com"
    ],
    "Access-Control-Allow-Credentials": [
      "true"
    ],
    "Set-Cookie": [
      "REDACTED"
    ],
    "Cache-Control": [
      "no-cache, private"
    ]
  }
}

If I now navigate through the page without refreshing, I am getting these logs:

[
  {
    "level": "info",
    "ts": 1748417450.7091546,
    "logger": "http.log.access.log0",
    "msg": "handled request",
    "request": {
      "remote_ip": "10.0.1.1",
      "remote_port": "53060",
      "client_ip": "10.0.1.1",
      "proto": "HTTP/1.1",
      "method": "GET",
      "host": "api.example.com",
      "uri": "/api/v1/project?filter%5Bname%5D&page%5Bsize%5D=10",
      "headers": {
        "Accept-Encoding": [
          "br, gzip, deflate"
        ],
        "Sec-Fetch-Mode": [
          "cors"
        ],
        "Accept-Language": [
          "de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7"
        ],
        "Sec-Fetch-Site": [
          "same-origin"
        ],
        "X-Forwarded-Proto": [
          "https"
        ],
        "X-Forwarded-Host": [
          "api.example.com"
        ],
        "Cookie": [
          "REDACTED"
        ],
        "Dnt": [
          "1"
        ],
        "Sec-Ch-Ua-Mobile": [
          "?0"
        ],
        "Cf-Visitor": [
          "{\"scheme\":\"https\"}"
        ],
        "Via": [
          "2.0 Caddy, 1.1 Caddy",
          "1.1 Caddy"
        ],
        "Sec-Ch-Ua-Platform": [
          "\"macOS\""
        ],
        "Cf-Ray": [
          "946c0c89dde331cb-EWR"
        ],
        "Sec-Ch-Ua": [
          "\"Not.A/Brand\";v=\"99\", \"Chromium\";v=\"136\""
        ],
        "Accept": [
          "application/json"
        ],
        "User-Agent": [
          "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Safari/537.36"
        ],
        "Cf-Ipcountry": [
          "DE"
        ],
        "Priority": [
          "u=1, i"
        ],
        "Cf-Connecting-Ip": [
          "2003:a:42f:2d00:a8ca:92d0:e63d:xxx"
        ],
        "Referer": [
          "https://example.com/project"
        ],
        "Cdn-Loop": [
          "cloudflare; loops=1"
        ],
        "X-Forwarded-For": [
          "10.0.2.1"
        ],
        "Sec-Fetch-Dest": [
          "empty"
        ]
      }
    },
    "bytes_read": 0,
    "user_id": "",
    "duration": 0.110588272,
    "size": 255,
    "status": 200,
    "resp_headers": {
      "Content-Type": [
        "application/json"
      ],
      "Access-Control-Allow-Credentials": [
        "true"
      ],
      "Cache-Control": [
        "no-cache, private"
      ],
      "Content-Encoding": [
        "gzip"
      ],
      "Vary": [
        "Accept-Encoding"
      ],
      "Access-Control-Allow-Origin": [
        "https://example.com"
      ],
      "Set-Cookie": [
        "REDACTED"
      ],
      "Date": [
        "Wed, 28 May 2025 07:30:50 GMT"
      ]
    }
  }
]

As you can see, my IP is now stored in the header:

"Cf-Connecting-Ip": [
          "2003:a:42f:2d00:a8ca:92d0:xxx:xxx"
        ],

So what I learn from that: The server-side fetching that happens on first page load does not forward the ip of the user. Technically, the webserver1 performs a request, which goes through cloudflare proxy again and so the IP of the nat gateway is stored in the header:

"Cf-Connecting-Ip": [
        "public.ip.of.webservers.nat.gateway"
      ],

I cannot work with this IP when it comes to rate-limiting on the Laravel-side, so the question is, whether I can force the proxy to send the requesting user's IP on initial page load.

First approach to this issue

As @manchenkoff pointed out that there is a possibility to Forward context headers, I might try this.

But before going down that way, I need your help, as I am not that experienced with nitro and h3: Is this the correct approach? Is it possible to proxy those initial requests including the user's ip this way?

[manchenkoff]

Is this the correct approach?

In this particular situation, I don't think there are "correct" or "incorrect" approaches. This is just an example of passing headers from SSR to the external client without implementing a complicated API layer in your app.

Is it possible to proxy those initial requests including the user's ip this way?

I've never worked with CloudFlare, so I cannot tell for sure. But I would definitely start with checking request input/headers on the Nuxt side first. Usually, if you have this information in the first request coming from the client to Nuxt app via both CF and LB, it should contain some information about the IP. If so, then you can add this header to be passed to your Laravel API, even if it goes via CF/LB again.

Afaik, in your case, it would be either X-Forwarded-For or CF-Connecting-IP