net::ERR_CONNECTION_CLOSED на удаленном сервере, если в монго-документе содержится более 7 поддокументов

Я разрабатываю проект MEAN с угловой 4.1.0.

На моем localhost все работает без ошибок. Однако при развертывании на сервере поиск пользователя с более чем 8 парами вопрос-ответ вызывает ошибку net::ERR_CONNECTION_CLOSED в запросе xhr, который запускает модуль angular http.

Цифровая океаническая капля, на которой я размещаю, использует обратный прокси-сервер nginx и использует SSL-сертификат letsencrypt. Я пытался:

  • Перезапуск сервера, службы nginx, node.js и т. Д.
  • Увеличение client_max_body_size в 20M в конфигурационном файле nginx
  • Увеличение large_client_header_buffers Размер до 128k в конфигурационном файле nginx

Другие важные факты:

  • GET запросить qapairs?jwt=ey.. никогда не достигает приложения node.js
  • Там нет упоминания о запросе в /var/log/nginx/error.log
  • Неудачные запросы, показанные в /var/log/nginx/access.log являются следующими:

    89.15.159.19 - - [08/May/2017:14:25:53 +0000] "-" 400 0 "-" "-"
    89.15.159.19 - - [08/May/2017:14:25:53 +0000] "-" 400 0 "-" "-"
    

Пожалуйста, укажите мне возможные направления.


Скриншоты вкладки сети Chrome Dev Tool

  1. После входа в учетную запись, где есть только 7 пар ответов на вопросы После входа в учетную запись, где есть только 7 пар ответов на вопросы

  2. Затем, после перехода на mlab.com и добавления вручную другой пары ответов на вопрос в ту же учетную запись, а затем обновления страницы (обратите внимание на количество вопросов в настоящее время 8) После перехода на mlab.com и добавления пары ответов на вопрос в ту же учетную запись вручную, а затем обновления страницы

  3. Наконец, после входа и выхода из той же учетной записи (обратите внимание на запрос xhr qapairs?jwt=ey... вернул ошибочный статус) После входа и выхода из той же учетной записи

/ и т.д. / Nginx/ сайты с поддержкой / по умолчанию

# HTTP — redirect all traffic to HTTPS
server {
    listen 80;
    listen [::]:80 default_server ipv6only=on;
    return 301 https://$host$request_uri;
}

# etc

# HTTPS  ^ ^  proxy all requests to the Node app
server {
    # Enable HTTP/2
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name subdomain.example.com;

    # Use the Let ^ ^ s Encrypt certificates
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # Include the SSL configuration from cipherli.st
    include snippets/ssl-params.conf;

    # Increase allowed URL length     
    large_client_header_buffers 4 128k;

    # Increase max body size
    client_max_body_size 20M;

    location / {
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-NginX-Proxy true;
        proxy_pass http://subdomain.example.com:3001/;
        proxy_ssl_session_reuse off;
        proxy_set_header Host $http_host;
        proxy_cache_bypass $http_upgrade;
        proxy_redirect off;
    }
}

QA-pairs.service.ts

Ошибка ловится здесь, в getQAPairs функция. Будучи переданным обратному вызову в catch функция а ProgressEvent объект с type собственностью error , eventPhase из 2 ,

@Injectable()
export class QaPairsService {
  /* etc */

  getQAPairs () {
    const jwt = localStorage.getItem('jwt') ? `?jwt=${localStorage.getItem('jwt')}` : ''

    return this.http.get(this.qapairsUrl + jwt)
      .map(response => {
        this.qapairs = response.json().map((qapair: IQAPair) => new QAPair(qapair))
        this.qapairsChanged.emit(this.qapairs)
        return this.qapairs
      })
      .catch(
        (error: any) => {
          error = error.json()
          this.errorsService.handleError(error)
          return Observable.throw(error)
        }
      )
  }

  /* etc */
}

2 ответа

Решение

Решение:

/ и т.д. / Nginx/ сайты с поддержкой / по умолчанию

 # другой код здесь

сервер {

   # другой код здесь

   # Увеличьте максимальные размеры http2
   http2_max_field_size 64k; 
    http2_max_header_size 64k;

} 

Причина, по которой я обнаружил, что это так трудно отлаживать, была в том, что

нет упоминания о запросе в /var/log/nginx/error.log

и я не осознавал, что nginx обладает способностью быть более многословным с его регистрацией (дух)

Итак, после изменения /etc/nginx/sites-enabled/default включать

server { 
    error_log /var/log/nginx/error.log info;
}

Я видел

2017/05/08 16:17:04 [info] 3037#3037: *9 client exceeded http2_max_field_size limit while processing HTTP/2 connection, client: 89.15.159.19, server: 0.0.0.0:443

это было сообщение об ошибке, в котором я нуждался.

Мне это помогло!!! К сожалению, сообщений об ошибках не было. Помогает мне:

      client_header_buffer_size 1k; large_client_header_buffers 4 4k;
Другие вопросы по тегам