Я развертываю свой сервер узлов на AWS и столкнулся с проблемой. Каждый раз, когда я пытаюсь подключиться к своему экземпляру через HTTP, я получаю эту ошибку
Ошибка: подключите ECONNREFUSED [ПУБЛИЧНЫЙ IP-адрес ЭКЗЕМПЛЯРА]:80
Я развертывал серверы много раз, но впервые сталкиваюсь с этой конкретной проблемой. Хотелось бы немного помощи в этом.
Ниже приведена некоторая информация, которую я собрал для устранения проблемы.
Настройки группы безопасности
ПОРТ 80 открыт
Настройки VPC
Конфигурация Nginx
server {
listen 80;
location / {
proxy_pass http://localhost:3000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
статус sudo systemctl nginx
● nginx.service - The nginx HTTP and reverse proxy server
Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; preset: disabled)
Active: active (running) since Fri 2024-07-19 07:22:44 UTC; 17min ago
Process: 31332 ExecStartPre=/usr/bin/rm -f /run/nginx.pid (code=exited, status=0/SUCCESS)
Process: 31333 ExecStartPre=/usr/sbin/nginx -t (code=exited, status=0/SUCCESS)
Process: 31334 ExecStart=/usr/sbin/nginx (code=exited, status=0/SUCCESS)
Main PID: 31335 (nginx)
Tasks: 2 (limit: 1114)
Memory: 2.2M
CPU: 54ms
CGroup: /system.slice/nginx.service
├─31335 "nginx: master process /usr/sbin/nginx"
└─31336 "nginx: worker process"
нетстат -tunlp
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:27017 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN -
tcp6 0 0 :::3001 :::* LISTEN 28321/node /home/ec
tcp6 0 0 :::3000 :::* LISTEN 28193/node /home/ec
tcp6 0 0 :::22 :::* LISTEN -
udp 0 0 127.0.0.1:323 0.0.0.0:* -
udp 0 0 172.31.17.134:68 0.0.0.0:* -
udp6 0 0 ::1:323 :::* -
udp6 0 0 fe80::80:45ff:fef1::546 :::* -
статус
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: permissive
Mode from config file: permissive
Policy MLS status: enabled
Policy deny_unknown status: allowed
Memory protection checking: actual (secure)
Max kernel policy version: 33
Еще пара замечаний, на которые стоит обратить внимание
curl http://localhost:80/
в системе возвращает действительный ответ от сервера Node.Это наводит меня на мысль, что запрос, возможно, не доходит до Nginx или у Nginx нет правильных разрешений.
Спасибо, что нашли время для этого. [INSTANCE IP]:3000 также генерирует «connect ECONNREFUSED». (Обновлено: еще немного информации. SSH с файлом ключа работает нормально, к этому приводят только http-запросы)
возможно, проверьте, включен ли брандмауэр на уровне ОС? Кроме того, поскольку перед экземпляром нет LB, находится ли экземпляр в общедоступной подсети (имеет ли подсеть маршрут к интернет-шлюзу)?
Итак, у меня была возможность настроить новый экземпляр EC2, поскольку это была моя учетная запись. Итак, я настроил базовый сервер Node и подключился напрямую к порту 3000 через Интернет, и он ответил. Затем я установил Nginx, и он тоже работал нормально. Я начал добавлять вещи одну за другой, проверяя статус подключения.
Оказывается, виноват был iptables-services
Так как у меня нет в этом необходимости. Я просто удалил его со своего основного сервера, и он начал подключаться. Хотя я не знаю, в чем заключалась реальная проблема, поскольку все мои правила были правильно настроены.
Команды для удаления были
sudo systemctl stop iptables
sudo yum remove iptables-services
Хорошо, что вы нашли проблему. Только для других читателей. Вероятно, просто слепо удалять iptables из экземпляра EC2 — не лучшая идея. Бывают случаи, когда iptables невозможно полностью заменить группами безопасности. Проверьте это, чтобы увидеть несколько примеров. Прежде чем удалять, убедитесь, что он вам не нужен.
Да, в моем случае это имело смысл, потому что мне не нужна была эта услуга, но вы правы, бездумное удаление ее может быть вредным.
Давайте попробуем устранить неполадки, связана ли проблема с конфигурацией сети экземпляра или конфигурацией nginx. Будет ли это работать, если вы сделаете запрос к [INSTANCE PUBLIC IP]:3000 напрямую?