Does WispByte's reverse proxy overwrite (not just pass through) X-Forwarded-For?

Hi all, I'm running a Python (aiohttp) app on a single allocated port/subdomain through WispByte, and it includes an admin dashboard with its own IP based rate limiter (to blunt login brute forcing / API abuse). Right now my rate limiter reads the client IP from the header when present, falling back to the raw TCP peer address otherwise. Before I turn that on in production, I want to make sure I understand WispByte's networking setup, because trusting blindly is only safe if it's impossible for an end user to control that header's final value. Specifically: 1. Does WispByte put a reverse proxy / load balancer in front of the single port that's allocated to my process, or does the client connect directly to my process over a plain TCP passthrough? 2. If there IS a proxy in front of it: does it overwrite with the real client IP it sees on its own edge connection, or does it just append to / forward whatever value the client already sent ? (These are very different — if a client can set their own and have it reach my app unmodified or merely appended to, then any user can spoof their IP and bypass IP based rate limiting / bans.) 3. If there's no dedicated proxy and it's a raw TCP passthrough to my process, can I confirm that (the raw socket peer address my app sees, via Python's aiohttp) is already the real, unspoofable client IP in that case? 4. Is there any other header (e.g. , , or a WispByte specific one) that IS guaranteed to be set/overwritten by your infrastructure and therefore safe to trust for this purpose? Basically: I want to know whether I should trust for security relevant IP checks on this hosting, or whether I should ignore it entirely and rely on the raw socket peer IP instead. Thanks to all of you