Hi,
I have an onpremise setup with Nginx as a reverse proxy on https://some.fqdn.com:8080, but only the RavenJsDsn with Raven-JS works, the RavenDsn from C#/.NET does not work unless i hook them up to the lan hostname:9000.
How do i figure out why only one type of logger works on an fqdn, but both work on lan?
Is the SSL certificate on the https endpoint valid? By default only calls to trusted certificates are sent by .NET
If you can test with a console application, any errors within the Raven-csharp will be displayed on the console.
Hi,
Yes, the certificate is valid, i’ll try and test a console application.
But why is that different for Raven-JS then?
Dennis
Hi bruno,
Made a console app that works fine with https:// but still nothing appears in sentry.
What now?
So, it turns out adding Jira Integration, but not configuring it, is the culprit. I’m not even gonna start to wonder how that could possibly disable event handling, but only from https and fqdn’s. Good luck!
Any errors within the SDK get output to the console. Strange that nothing shows up on the console and also the event doesn’t get sent to Sentry.
Could you share the code of your console app?
var client = new RavenClient("https://<secret-dsn-here>@sentry.innomate.com:8080/3");
var msg = "test message from console application";
var sentryMsg = new SentryMessage(msg);
client.Capture(new SentryEvent(sentryMsg));
var evt = new SentryEvent(new Exception("test exception from console application"));
client.Capture(evt);
Console.Write("done");
Console.ReadKey();
sending both a message and an exception in this case.
I looked into other people with missing events and they were mentioning filters, but i checked that and nothing has been filtered. It’s very strange.
The filters should apply regardless whether your sentry instance is accessed through https or http. Sentry has a repo on github with a docker-compose: https://github.com/getsentry/onpremise
You’d have a local Sentry instance accessible via http. If you could reproduce the error with a client using that, and provide us with such client, it’d make it easier for us to reproduce your issue.
– Just realized your issue is with https instead. How are you adding HTTPS to Sentry? Do you have a reverse proxy in front of it? If so how’s the setup?
I’m using Nginx, here is the config:
server {
listen 8080 ssl;
server_name sentry.innomate.com;
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_redirect off;
# keepalive + raven.js is a disaster
keepalive_timeout 0;
# use very aggressive timeouts
proxy_read_timeout 15s;
proxy_send_timeout 15s;
send_timeout 15s;
resolver_timeout 15s;
client_body_timeout 15s;
# buffer larger messages
client_max_body_size 5m;
client_body_buffer_size 100k;
# Start Sentry Stuff
set_real_ip_from 10.0.0.0/8;
real_ip_header X-Forwarded-For;
real_ip_recursive on;
ssl_certificate /opt/fullchain.pem;
ssl_certificate_key /opt/innomate.pem;
# End Sentry Stuff
location / {
proxy_pass http://localhost:9000;
}
}
Just realized it says set_real_ip_from 10.0.0.0/8 and the machine is on vpn network 172.31.103.0/16 docker is on 172.17.0.0, but not sure if that matters, since RavenJS works just fine.
Do you have some logs from nginx? Do you see the requests from the C# app going through it?
How do they compare, the raven-js calls and raven-csharp ones?
Sentry.io also uses nginx and there are lots of both raven-js and raven-csharp clients pushing data in so I don’t think it’s something in the C# SDK itself. I believe it’s more likely to be in the infrastructure.
You could also hook into the internal error callback of the SDK
ravenClient.ErrorOnCapture = exception =>
{
// Custom code here
};
I hope we see something there. Shed some light into this 
I added that exception handling code to our system and I get this exception when debugging:
{“The underlying connection was closed: An unexpected error occurred on a send.”}
{“Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.”}
It works in the console application though, which is a bit weird.
Sounds like your server is dropping the connection:
“Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.”
Since it works on plain HTTP, doesn’t seem to be a problem with Sentry either. The web server you use for SSL offloading perhaps?
It also works just fine with https:// from browser console, not sure why my nginx setup would terminate that specific connection, also, there is nothing in the nginx error or access logs, the connection attempt never seems to arrive 
You might have already tried but have you seen the different cases listed on StackOverflow?
Especially the one regarding TLS requirements could be your case. Is the client Windows on a latest patch?
Again, the console application works just fine, on the same .NET 4.6.1 framework. But from Webforms or MVC either the connection dies or is never attempted.
I tested with another old .NET project, same issue. Tried downgrading to .NET 4, downgrading SharpRaven, same thing. No connection.
Unfortunately without being able to reproduce it here I’m out of ideas.
Can you create an account to sentry.io? It’s free and no credit card is required or anything. Use the Sentry.io DSN. That will help narrow down the issue. If you can reproduce it there, I could try to setup the same environment as you have and reproduce it here.
Or if you could you prepare some repro it would help a lot.
Also, we’re preparing to start working on a new SDK which will use HttpClient instead of the current WebRequest. Would you be interested in trying a preview? It’s a few days away still but we could keep in touch in regards to that in parallel to troubleshooting this issue.
This seems to fix it:
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 | SecurityProtocolType.Tls11;
got some great pointers from the SO article you linked, thanks!
Glad it’s fixed! Would still love if you’d try the preview when it’s out 
Drop me a line at bruno@sentry.io if you can.