### Check for existing issues

- [x] I have searched the existing issues and checked that my issue is not a duplicate

### What happened?

On current `litellm_internal_staging` at commit `65ca095d4d15a82372e53a547a2390a69f7e1797`, `general_settings.allowed_ips` rejects a legitimate client whenever `use_x_forwarded_for: true` receives the normal multi-hop form of the header

[`_get_request_ip_address`](https://github.com/BerriAI/litellm/blob/65ca095d4d15a82372e53a547a2390a69f7e1797/litellm/proxy/auth/auth_utils.py#L20-L30) returns the complete header string, and [`_check_valid_ip`](https://github.com/BerriAI/litellm/blob/65ca095d4d15a82372e53a547a2390a69f7e1797/litellm/proxy/auth/auth_utils.py#L33-L49) compares that string directly with each configured IP

For example, an allowlist containing `203.0.113.10` does not match this header:

``` X-Forwarded-For: 203.0.113.10, 10.0.0.2 ```

The observed client value is `"203.0.113.10, 10.0.0.2"`, so the check returns false even though the client address is explicitly allowed

The expected behavior is to resolve one client IP from the hop list using the existing trusted-proxy/client-IP utilities, then compare that address with `allowed_ips`…