Это сообщение об ошибке иногда появляется, когда я пытаюсь отправить электронное письмо с помощью пакета npm sendgrid/mail. Это работает в большинстве случаев.
{ Error: connect ETIMEDOUT 169.45.89.179:443 at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1104:14) errno: 'ETIMEDOUT', code: 'ETIMEDOUT', syscall: 'connect',
address: '169.45.89.179', port: 443 } [bugsnag] Reported an unhandled rejection… Error: Error: connect ETIMEDOUT 169.45.89.179:443 at SendGrid.send.then.catch.e (/home/leoqiu/foodnome-api/build/src/utils/emailHelpers.js:143:11)
Мой сервер узлов отправляет его со следующим кодом:
export const sendVerifyMail = (to: string, token: string) =>
SendGrid.send({
to,
from: { email: '..' },
subject: 'Verify you..',
dynamic_template_data: {
header: 'Verify your account',
text:
'Please use the button below to continue the process.',
c2a_link: `${serverAddress}/api/user-account/verify?token=${token}`,
c2a_button: 'Verify'
},
template_id: 'd-0f6411434fbc4896bf389e3945affd5d'
} as any)
.then(d => d)
.catch(e => {
console.info(e);
throw new Error(e);
});





Я не думаю, что это проблема с вашим кодом или на вашей стороне сети, если только у вас не было общих проблем с подключением в то же время.
ip 169.45.89.179 разрешается в домен sendgrid, так что это, вероятно, проблема на их стороне, чтобы дважды проверить это, вы можете настроить непрерывный пинг на 8.8.8.8 или запустить другие настройки мониторинга сети, чтобы убедиться, что ваше соединение стабильно.
Если ваше соединение не является проблемой, я бы просто сообщил им об этом вместе с любыми журналами, которыми вы готовы поделиться, ваш исходный IP-адрес и время возникновения ошибок тайм-аута, вероятно, будут им полезны.
Странная вещь находится на стадии, мой сайт работает просто отлично. Я получаю электронную почту с точно такой же настройкой. Но не на производстве. Я не уверен, что может быть причиной проблемы.
он выходит из строя в 100% случаев в производстве? Убедитесь, что трафик с рабочего сервера разрешает трафик на этот порт, запустите «telnet 169.45.89.179 443» и посмотрите, подключается ли он с вашего рабочего сервера.
вы правы, это связано не с моим производством, а с постановкой
Вы знаете, как это исправить?
это, вероятно, правило брандмауэра, установленное либо на сервере, либо в сети, если есть человек, ответственный за сеть, ему нужно разрешить трафик на порт
Я уже отключил все ufw. Что-то еще может быть причиной этого?
находится ли рабочий сервер в той же сети или VPC, что и ваш промежуточный сервер, имеет ли он тот же интернет-шлюз?
Я так думаю, я только что купил один и тот же сервер 3 раза, 2 для производства, 1 для сцены. Все они проходят через cloudflare
а рабочие серверы работают через балансировщик нагрузки на cloudflare
Я только что протестировал «telnet 169.45.89.179 443» на универсальном экземпляре aws ec2, и он подключается без проблем, поэтому не похоже, что конечная точка является проблемой, я бы просто открыл билет с помощью cloudflare и посмотрел, возможно есть функции безопасности, включенные только для производства, или, возможно, балансировка нагрузки каким-то образом портит соединение с sendgrid. Если на ваших производственных серверах нет никаких сетевых правил, это должно быть что-то в сетях, которые вы используете.
спасибо, я пробовал и с другими своими серверами, и все вроде бы работало нормально. Должно быть, с балансировщиком нагрузки все портится. Я создам тикет и проверю
Кажется, что адрес электронной почты ненастоящий, а электронная почта из sendgrid не доставлена в папку «Входящие», поэтому статус будет
Bouncedв sendgrid, а запрос будет истечен по тайм-ауту.