Request.RemoteAddress does not seem to work

Hello guys,

Do i need special packages installed on linux in order to have Request.RemoteAddress to work ?

It seems that if i add this in the App.HandleURL event , the result always comes empty .

i need to be able to log the stats that come on HandleURL for different purposes and it seems that for some reasons a lot of those parameters from Request come empty.

OS : Linux , Debian 11
XOJO : 2023R1.1


How are you deploying this application? If you are using a reverse proxy or if it’s behind a CDN, you may need to get the address from a Header.

Hi Ricardo,

Well currently the app is deployed via Lifeboat and it is on dedicated servers in LAN environment, so customers could connect to it only from LAN or via VPN and i need for some certain restrictions to be able to see who and how is doing that .

Now, on the old app i did before in v1 using luna i guess i used to get the Request from the session side and get as well the logged user, but as the Session does not handle that anymore, how i will be able to pass the Request from the session and find which user accessed what ? as V2 is little bit confusing honestly.

The weird part is that it does work properly if i have the app serving on a public ip on a cloud server , using same code, but when i run that behind the lan i don’t get anymore the local ip, i do get it in the header as “X-Forwarded-For”:“”


That’s normal, when you expose the app directly, it will directly receive the request from the remote address. When the app is behind a reverse proxy, the remote address will be the proxy address (i.e. if it’s on the same machine), so you will have to get the user IP from a header (like X-Forwarded-For, but there are others, it depends on the deployment)

Xojo normally takes care of replacing RemoteAddress with the value coming from X-Forwarded-For. I guess there should be something else going on.

Well based on my knowledge Lifeboat uses NGINX as proxy and it has exactly the same setup on both servers so in this case the access to the app is not done from localhost , it is done in within the lan for the lan apps and over the internet for the cloud one , in this case the app behaves differently based on the location where it is used.

If on the cloud i see the public ip of the user, i guess in the LAN i should see the private ip of the user same as i see the public one, via response.RemoteAddress, but so far in lan i see it only in Header, that was the reason i asked maybe there is something to be installed on the server in order to work, are there any dependencies that the web app depends in order to behave like this ? , so far both have Lifeboat service installed which should install all the dependencies needed for XOJO apps to run so in a way both servers are identical in the way they were setup, just that one shows one not .

Just to add info, Lifeboat is built to pass along the headers that Xojo expects for things like RemoteAddress (X-Forwarded-For).

Is it perhaps nginx behaving differently on your LAN vs the web?

Considering Lifeboat would set up both servers the same way, I’m not really sure what would need changes in Lifeboat.

Hi guys, exactly that’s my point as well Tim, as the servers are basically identical, clean install, then run Lifeboat, it does the setup and done, but still ,when i access the bage and monitor the Request.RemoteAddress i don’t get needed data on local but i do on the publicly available server, that was the weird part, so i’m not sure nginx is the issue here or lifeboat, i’ll dig more into it.


Have you tried setting up an app to iterate the headers received by your app from nginx on the LAN? It would be useful to know what, if any, are actually being passed.

Another test worth a try would be iterating those headers with a different platform. In other words, not a Xojo app running behind the nginx reverse proxy. This would help us identify if the issue was specific to Xojo.

I’m happy to help with what I can, and I’d be very interested in any changes Lifeboat might need. Please keep me updated, and any passers-by with insight are welcome to reach out to me even if the information is not to share. <>