Dlaczego maile z VPS nie dochodzą? Praktyczne pułapki i rozwiązania
Jeśli korzystasz z VPS do automatyzacji wysyłki maili, np. przez n8n, możesz nagle zauważyć, że wiadomości nie docierają do odbiorców. Ten problem nie zawsze wynika z błędnej konfiguracji workflow – często winne są domyślne blokady po stronie dostawcy serwera. Zobacz, na co trafiłem podczas wdrożeń u klientów i jak wyjść z pułapek, które nie są opisane w oficjalnych poradnikach.
Blokada portów SMTP na VPS – Hetzner i nie tylko
Na nowych serwerach VPS w Hetznerze wychodzące połączenia na portach SMTP 25 i 465 są domyślnie zablokowane. Efekt? Wysyłka maili z n8n kończy się błędem ETIMEDOUT po kilku minutach oczekiwania. Ten komunikat pojawia się niezależnie od konfiguracji credentiala, jeśli próbujesz użyć tych portów. Rozwiązanie jest jedno: przełącz się na port 587, wybierz opcję STARTTLS i wyłącz SSL/TLS w ustawieniach połączenia SMTP w n8n. Dopiero wtedy wiadomości wychodzą bez problemu.
Gdzie szukać błędów, gdy maile z VPS nie dochodzą?
Jeśli workflow w n8n działa poprawnie lokalnie, a na VPS przestaje wysyłać maile, sprawdź logi kontenera lub panelu n8n. Błąd ETIMEDOUT to niemal zawsze znak, że port jest zablokowany na zaporze sieciowej lub przez dostawcę. Warto testować połączenie SMTP narzędziem telnet bezpośrednio z VPS: komenda 'telnet smtp.gmail.com 25' powinna pokazać, czy port jest otwarty. Jeśli nie, przejdź na port 587.
Agent AI i fałszywe potwierdzenia wysyłki
Przy wdrażaniu agentów AI do obsługi zgłoszeń mailowych zdarza się, że model językowy potwierdza użytkownikowi wysyłkę, mimo że narzędzie zwróciło błąd. Przykład: agent informuje o sukcesie, choć n8n zwrócił komunikat ETIMEDOUT. W instrukcji agenta warto wprost zakazać potwierdzania wysyłki bez sprawdzenia statusu workflow i zaproponować alternatywę, np. kontakt telefoniczny pod +48 509 260 511.
Zmiana credentiala SMTP w n8n – ukryta pułapka
Po zmianie credentiala SMTP w n8n (np. po korekcie portu lub loginu) workflow może nadal zgłaszać błąd uwierzytelnienia, mimo że panel pokazuje poprawne połączenie. To efekt trzymania danych logowania w pamięci podręcznej. Pomaga dopiero restart kontenera: 'docker compose restart n8n' odświeża credentiale i pozwala workflow nawiązac nowe połączenie.
Checklista: co sprawdzić, gdy maile z VPS nie dochodzą
- Czy używasz portu 587 z STARTTLS i wyłączonym SSL/TLS?
- Czy port 25/465 nie jest zablokowany przez dostawcę VPS?
- Czy po zmianie credentiala SMTP zrestartowałeś n8n?
- Czy agent AI nie potwierdza sukcesu bez sprawdzenia statusu workflow?
- Czy logi n8n wskazują na błąd ETIMEDOUT lub AUTH?