Stuck on an issue?
Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
X-Forwarded-For isn't used in transactions
See original GitHub issuePackage
Sentry.AspNetCore
.NET Flavor
.NET Core
.NET Version
5.0.9
OS
Linux
SDK Version
3.16.0
Self-Hosted Sentry Version
No response
Steps to Reproduce
- Following docs as described in #258 to
UseForwardedHeaders(I’m actually hosted on Fly and using theFly-Client-IPheader, but I don’t think this should make a difference) - Add
UseSentryTracing()right afterUseRouting()in my Startup.cs - Set TracesSampleRate to 1.0 to ensure all transactions are recorded
- Send HTTP request to endpoint that deliberately throws an exception with the
Fly-Client-IPheader set to something noticable
Expected Result
- Error event has
User.IpAddressset to the value set in the header - Transaction
User.IpAddressset to the value set in the header
Actual Result
- ✔ Error event has
User.IpAddressset to the value set in the header - ❌ Transaction
User.IpAddressis not set to the value set in the header, but the IP of the requesting client.
Issue Analytics
- State:
- Created a year ago
- Comments:11 (7 by maintainers)
Top Results From Across the Web
Get User.IpAddress from X-Forwarded-For #258
For example, we use a non-standard header for setting client IP, so just using ... X-Forwarded-For isn't used in transactions #1576.
Read more >X-Forwarded-For Header Insert Fail
If an existing x-forwarded-for header doesn't exit, then you aren't doing an insertion at all. In this case you need a rewrite action...
Read more >Reason for browser not showing X-Forwarded-For headers
The easiest explanation of why you are not seeing that header is that the client sending the request did not manually add it....
Read more >Application Insights IP address collection - Azure Monitor
The IP address isn't collected locally when the X-Forwarded-For header is set. When the incoming IP address list has more than one item, ......
Read more >Configuring "X-Forwarded-For” Headers
Using the XFF headers, the service can apply the appropriate sub-location policy to the transaction, and if Enable IP Surrogate is turned on...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Hi @mattjohnsonpint, thanks for taking a look. I feel like a bit of a fool now… I thought I had tested this locally with explicitly setting the
Fly-Client-IPheader, but apparently not because trying it now has worked.Something funky is going on in the Fly environment I think, I can see the headers in the transaction for my staging environment, but it seems
UseForwardedHeadersisn’t triggering for some reason (incorrect IP for events too). This happens regardless whether I’m usingFly-Client-IPorX-Forwarded-For, so it might be pointing to an issue in how Fly passes these headers given it’s working locally. Thanks for your help and sorry to waste your time 😅 I will see if I can get help on Fly’s forums (I’ll link the topic I eventually make here to maybe help a future visitor 🙂)Just a quick note that I figured out what was going on,
KnownNetworksorKnownProxiesneeds to be configured for proxies situated on anything other than loopback addresses to work. This specified in the MS docs, but isn’t very prominant which is why I missed it. And why it worked locally but not on Fly 🙂 Hope this helps someone else.