Client IP Getting Masked by Sentry Proxy


I built a proxy for Sentry events in order to create Sentry projects on demand and route traffic into the appropriate project based on metadata in the payload. We have a number of web properties with raven-js integration, so managing from a single place is desirable. This is working great, however, I noticed that we lose the client IP tracking - all of the events appear to originate from two IPs, which correspond to the public IP addresses of our proxy cluster.

I’ve double checked our proxy implementation, and its correctly setting the X-Forwarded-For header to include the original client IP. In fact, we’re using Golang’s httputil.ReverseProxy, so you can see the code here:

Does honor X-Forwarded-For? If not, can it? Is there another alternative to get the client IP tracking working?


Bump - can anyone at Sentry chime in?

The proxy would need to conform to the standard specs, and Sentry would need to be configured to accept the appropriate headers. If you’re hosting it yourself, this is the same as the Nginx configuration. If this is it’s currently not possible.

Thanks Zeeg. Are you referring to spoofing the client IP, via set_real_ip_from in the Nginx config? I saw that here:

If so, I can probably do that with a custom http.Transport on the reverse proxy, but it certainly would be nice if Sentry supported the standard X-Forward-For header, especially considering how many users could be sitting behind proxies. Is that possible?

The reason we don’t support it on the upstream server is that it’s based on a trust system. If we just accepted it by default any user could override their IP by passing that header.

That said, we could possibly have a setting which accepts it.

Hmm, spoofing might be harder than I thought. Golang seems to try hard to prevent that.

Thinking on it some more though, I’m not sure I follow the trust thing. Couldn’t an end user do any number of modifications to the data that is sent? In fact, there is nothing prevent a malicious user from invoking Raven.captureException() in the browser or spamming the endpoint with gibberish (the project id and client key are in plaintext, after all). And of course, a particularly determined user could spoof their IP anyway (or hide behind some services that will).

I’m still in favor of accepting X-Forwarded-For by default, though per your suggestion an opt-in setting could work too. However, if it is at the project-level it would be great to have it configurable at creation time via the API. We’re in the process of rolling Sentry out to 100+ properties, and part of that integration is to automate the creation of the Sentry projects per-property. Requiring manual intervention for each new project wouldn’t be ideal.


The big thing with IPs is they’re the only reliable way we can prevent abuse.

e.g. You send data from X IP, we block X IP.

Regarding the option, pretty much everything these days is configurable via APIs, so this would be no different. I don’t know if you’d be able to do it from creation, but there’s other endpoints that we expose for mutating settings.

With that said, no promises on when we’ll actually deliver this feature. I definitely get the usability of it, but in terms of priorities its not something thats come up often. Someone may decide to take a stab at it given their interest, or if you’d like to we can help on a pull request. Otherwise it likely won’t happen at the very least before sometime next year.

so how can i resovle this problem ?

Any update on this? The number of users affected by an error/bug is useless if it cannot use X-Real-IP