We have a Java Spring Boot application that is behind a NGIX reverse proxy. Everything works as expected when the using HTTP - the API responds times are quit fast.

Once the protocol is switched to HTTPS, API response times decrease considerably. In the browser dev tools the request appear as pending for a very long time. In the backend the API serving threads do not return and ultimately fail to release DB connections.

As this is not happening when the API is directly accessed without NGINX in the middle and it is also not a thing when SSL is turned off, I think it is sth. wrong with the SSL configuration. So far I have no clue what it could be, as it looks pretty much standard to me. Any clues what might happen or how to troubleshoot the issue?

NGINX version:

$ nginx -v
nginx version: nginx/1.10.3 (Ubuntu)

The NGINX configuration looks like this:

server {
    listen 443 ssl http2;
    server_name something.de;
    access_log /var/log/nginx/something.access.log;
    access_log syslog:server=unix:/dev/log,facility=local7,tag=nginx combined;

    root  /usr/share/something/ui/web;
    index index.html index.htm;

    # SUPPORT-136 set max upload to 70M
    client_max_body_size 70M;

    location / {
        # SUPPORT-271 lock out unsupported browsers
        if ($http_user_agent ~ 'MSIE|Trident|Firefox|Opera') {
            rewrite ^.* /unsupportedBrowser.html break;
        if ($http_user_agent ~ 'iPhone;' ) {
            root  /usr/share/something/ui/iphone;
        index               index.html  index.htm;

    location /api {
        proxy_pass          http://upstream_something/api;
        proxy_read_timeout  180;
        proxy_hide_header   WWW-Authenticate;
        proxy_set_header    Host               $http_host;
        proxy_set_header    X-Forwarded-For    $proxy_add_x_forwarded_for;
        proxy_set_header    X-Forwarded-Proto  $scheme;

    # GZIP Compression of responses
    gzip on;
    gzip_disable "msie6";
    gzip_vary on;
    gzip_proxied any;
    gzip_comp_level 6;
    gzip_buffers 16 8k;
    gzip_http_version 1.1;
    gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;

    # SSL security
    ssl_certificate /etc/ssl/certs/STAR_something.bundle;
    ssl_certificate_key /etc/ssl/private/STAR_something.key;
    ssl_session_timeout 5m;
    ssl_protocols TLSv1.2;
    ssl_ciphers AES256+EECDH:AES256+EDH:!aNULL;
    ssl_prefer_server_ciphers on;
    ssl_dhparam /etc/nginx/dhparams.pem;

    # General security
    add_header X-Frame-Options SAMEORIGIN always;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
  • As it turns out, the NGINX settings are not to blame here. We switched the NGINX reverse proxy with an alternative for testing. It shows the same behaviour. So the conclusion for now is, that it must be something with the webapp behind the reverse proxy. We are investigating this. Mysterious! – spa Nov 27 '18 at 10:09

A common issue I've found is related to nginx buffering responses. When you turn off buffering, responses are passed from NGINX to the client synchronously.

To do this include the below line in your api location block.

proxy_buffering off;
| improve this answer | |
  • Sadly this has no positive effect. – spa Nov 21 '18 at 16:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.