I have a web site, that is visited by many different mobile devices and embedded devices.

Quite often I encounter the issue, that some devices cannot connect.

The reasons can be:

  • the device doesn't recognize an certain CA
  • the device is too old and would require an older protocol TLS1.1
  • the device requires an outdated crypto algorithm or just a crypto algorithm, that I didn't make available with me server conf.

As the devices are in remote locations, don't have easily accessible logs I would like to be able to analyze such issues with nginx logs.

I can do this by increasing the error-log log level to debug.

error_log  /var/log/nginx/errors_with_debug.log debug;

However this logs contain loads of things which I am not interested in.

Is there any way to log detailed information only if an ssl connection was refused but have a normal error log level for all other cases?

So far I enable debug logging, ask remote users who have issues with their devices to connect and record the the traces, disable debug level, reload nginx and analyze then the obtained traces.

In fact I would already be helped if I could just log the date and the ip address of any client that failed to connect due to SSL issues.

Ideally I'd also like to log the reason, but alerady knowing, that a connection was attempted but failed due to SSL would be very helpful.

  • Funny I think I saw an answer or a comment yesterday, that was pointing to nginx.com/blog/sampling-requests-with-nginx-conditional-logging Not it seems to have disappeared. Though I think this answer / comment was probably not helpful in my context as it is about sampling and about logging successful connections it could still have been interesting to be kept.
    – gelonida
    Apr 9, 2020 at 23:54

2 Answers 2


All the SSL handshake errors you mention are logged by nginx at an info level, so you don't need to enable debugging.

You don't mention which distribution you are using, but most systems nowadays come with SystemD so redirecting your logs to standard error:

error_log stderr info;

or syslog:

error_log syslog:server=/dev/log info;

will allow systemd-journald to capture all Nginx logs and administer their size. A simple:

journalctl -u nginx.service -a -p info

will allow you to list all debug messages above info level (assuming you use syslog).

If you need more data for certain clients, you can use Nginx's debug_connection:

events {

As you mention in your question, setting a log level of debug for all clients will certainly produce a lot of output. If you need to enable debugging you might do it on a per subsystem level. Although it is not documented in the documentation of error_log, this directive accepts also a finer subdivision of the debug level (cf. source code): debug_core, debug_alloc, debug_mutex, debug_event, debug_http, debug_mail, debug_stream. You are interested in the debug_event level, but you can add several in the error_log directive, e.g.:

error_log syslog:server=/dev/log debug_http debug_event;
  • Thanks a lot Piotr. Will check this a little. I found already one info message: SSL_do_handshake() failed (SSL: error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher)
    – gelonida
    Apr 11, 2020 at 22:49
  • You can generate more of them with curl and the --ciphers, --tls-max, --sslv3, --cafile and --capath switches. Unfortunately the list of cipher suites requested by the client does not appear even in debug. Apr 12, 2020 at 6:00
  • good thing: Error logs at info level are not requiring a lot of space. bad thing (as you said): neither debug nor info will help to identify which cyphers the client would have offered. But I think this gets me as close as possible to what I try to achieve.
    – gelonida
    Apr 12, 2020 at 23:05


  1. enable "debug"
  2. create pipe instead of logfile (ensure it won't be hurt by logrotation)
  3. create listener in background (cat awk, grep, sed, whatever, etc)
  4. restart nginx


error_log syslog:server=unix:/var/log/nginx.sock debug;

  • will this huge amount of logging not impact the performance in a negative way? What if the listening process dies. Will this stall the server?
    – gelonida
    Apr 9, 2020 at 23:50
  • In fact what you suggest as alternative is a unix domain socket, right? Same issue will it not slow down to have kilobytes of traces for each tiny request?
    – gelonida
    Apr 9, 2020 at 23:52
  • impact depends on how you'll filter the output, just passing the data through socket or pipe won't be noticeable.
    – GioMac
    Apr 10, 2020 at 0:03
  • p.s. never tried, shouldn't be a problem, but at least B option will work for 100%
    – GioMac
    Apr 10, 2020 at 0:04
  • OK will wait to see whether there will still be a solution that 'just' creates less logs instead of creating them and filtering afterwards with an additional process. If not will accept yours as answer
    – gelonida
    Apr 10, 2020 at 9:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .