Jak skonfigurować kontrolę TCP Port (pełny przewodnik)
Kontrola TCP Port otwiera połączenie TCP na wybranym porcie Twojego serwera i potwierdza, że połączenie (a jeśli to włączysz, także uzgadnianie TLS) się powiodło, opcjonalnie sprawdzając też, czy dane odsyłane przez usługę pasują do zadanego przez Ciebie wzorca. To właściwe narzędzie zawsze, gdy zależy Ci na "czy ta konkretna usługa nasłuchuje i odpowiada", a nie na "czy ten host odpowiada na ICMP" (to kontrola ping) albo "czy ta strona WWW poprawnie się ładuje" (to kontrola HTTP). SSH, SMTP, nasłuchy baz danych, przekaźniki pocztowe i każda inna usługa TCP niebędąca HTTP to naturalne przypadki użycia.
Url / Domain / IP
Wpisz cel jako host:port, na przykład example.com:22 dla SSH albo example.com:465 dla SMTPS - port jest częścią adresu, nie osobnym polem. Możesz też nadać monitorowi krótką nazwę, która pojawia się w alertach, raportach i widżetach statusu.
Ustawienia główne (Main Settings)
Nie ma osobnego zrzutu ekranu dla tej sekcji przy typie kontroli Port, ale korzysta ona z tej samej grupy Main Settings co każdy inny typ kontroli, więc każda kontrolka poniżej to dokładnie to, co zobaczysz w formularzu:
- Monitoring enabled: wstrzymuje albo wznawia kontrolę bez jej usuwania.
- Interval schedule / Cron schedule: uruchamiaj w stałym interwale (suwak biegnie od 1 minuty do 24 godzin) albo według wyrażenia cron dla wzorca, którego skala interwału nie potrafi wyrazić.
- Tags: etykiety oddzielone przecinkami do filtrowania i wyszukiwania na liście monitorów. Wyłącznie organizacyjne - nie wpływają na samą kontrolę.
- Full Log: zapisuje każdy pojedynczy wynik kontroli zamiast grupować identyczne powtarzające się wyniki.
- Open Stats: udostępnia stronę statystyk i logu tego monitora osobom niezalogowanym na Twoje konto.
- Attached monitors - DNSBL: uruchamia kontrolę czarnej listy DNS na tej samej domenie według własnego 12-godzinnego harmonogramu, niezależnie od interwału kontroli portu. Wykryty zły stan powiadamia zgodnie z subskrypcjami Down/Repeat w Alert Subscriptions.
- Attached monitors - Web Risk: uruchamia kontrolę Google Web Risk pod kątem złośliwego oprogramowania/phishingu na domenie, również według własnego harmonogramu. Ograniczona pakietem.
Konfiguracja żądania (Request Configuration)

- Connect over TLS/SSL: domyślnie wyłączone, co oznacza, że kontrola łączy się zwykłym gniazdem TCP. Włącz, żeby opakować połączenie w uzgadnianie TLS przed odczytaniem odpowiedzi - właściwy wybór dla usług w stylu HTTPS, SMTPS albo nasłuchu bazy danych wymagającego TLS. Włączenie tego odkrywa też podgrupę TLS Handshake pod Response Validation (poniżej) z politykami walidacji certyfikatu. Opis przy tym przełączniku wspomina "zwykłą usługę TCP (lub UDP)", ale nigdzie w tym formularzu nie ma wyboru protokołu: każda kontrola Port łączy się przez TCP. Jeśli musisz monitorować usługę UDP, ten typ kontroli obecnie nie udostępnia takiej opcji.
- DNS Server Selection: ta sama lista rozwijana co w innych typach kontroli. Default DNS servers at locations rozwiązuje hosta przez własne publiczne serwery DNS każdej lokalizacji monitoringu, zgodnie z lokalnymi regulacjami. Public DNS rozwiązuje przez publiczną pulę DNS, z opcjonalną listą wykluczonych resolwerów. Custom pozwala podać własne adresy IP serwerów DNS, po jednym w wierszu. Na koncie, z którego pochodzi ten zrzut ekranu, Public i Custom są zablokowane za banerem z propozycją podwyższenia pakietu, co jest ograniczeniem pakietu, a nie brakującą funkcją.
Weryfikacja odpowiedzi (Response Validation)

Domyślnie kontrola kończy się sukcesem, gdy połączenie się zakończy - a przy włączonym TLS/SSL, gdy zakończy się też uzgadnianie. Kontrolki tutaj pozwalają wymagać więcej niż to:
- Response Pattern (Wzór odpowiedzi): opcjonalne wyrażenie regularne, któremu musi odpowiadać odpowiedź. Po ustawieniu kontrola czyta do 1 MB odpowiedzi TCP (albo TLS, gdy włączone) i zawodzi, gdy wzorzec się nie zgadza; zostaw puste, żeby ocenić samo połączenie. (Starsza dokumentacja nazywała to "wzorcem wyszukiwania odpowiedzi TCP"; obecny interfejs opisuje to jako Response Pattern.) Ponieważ czytany jest tylko pierwszy 1 MB, umieść tekst, który dopasowujesz, blisko początku tego, co wysyła usługa - dobrze sprawdza się baner albo linia powitalna; treść wysyłana przez usługę później w długiej odpowiedzi nie zostanie zobaczona.
- TLS Handshake (widoczne tylko gdy Connect over TLS/SSL jest włączone): cztery niezależne przełączniki oceniające samo uzgadnianie. Require valid SSL certificate chain nie zalicza kontroli przy wygasłym, self-signed, z niezgodną nazwą albo źle powiązanym łańcuchem certyfikacie. Require strong TLS protocol (1.2 or higher) nie zalicza serwera, który oferuje tylko TLS 1.0/1.1 albo SSL. Block weak ciphers (128-bit or lower) nie zalicza kontroli, gdy wynegocjowany zestaw szyfrów jest 128-bitowy lub słabszy. Check SSL certificate revocation wykonuje podczas uzgadniania zapytanie online CRL/OCSP i nie zalicza kontroli przy unieważnionym certyfikacie; to osobne uprawnienie pakietowe niż pozostałe trzy.
- Expected IPs Validation: włącz to, żeby dodatkowo wymagać, aby DNS rozwiązywał Twojego hosta do jednego z adresów IP z podanej przez Ciebie listy, po jednym w wierszu. Jeśli host zacznie rozwiązywać się gdzie indziej - przejęcie DNS, nieaktualny rekord, migracja, której zapomniałeś tu zaktualizować - kontrola zawodzi, nawet jeśli nowy adres wciąż odpowiada.
Subskrypcje alertów (Alert Subscriptions)

- Subscribe all contacts to Up/Down events: subskrybuje wszystkie kontakty na Twoim koncie zarówno na alerty Up, jak i Down jednym ruchem.
- Chipy Down / Up / Repeat dla każdego kontaktu: Down uruchamia się przy przejściu w stan awarii, Up przy powrocie do działania, a Repeat wysyła ponownie powiadomienie Down według harmonogramu, dopóki monitor pozostaje w stanie Down.
- Search contacts: filtruje listę po nazwie lub adresie.
Subskrypcje raportów (Report Subscriptions)

- Subscribe all contacts to Weekly/Monthly reports: subskrybuje wszystkie kontakty na obie częstotliwości naraz.
- Chipy Daily / Weekly / Monthly dla każdego kontaktu: wybierz, jaki cykliczny e-mail z podsumowaniem uptime otrzymuje każdy kontakt, niezależnie od alertów w czasie rzeczywistym powyżej.
Lokalizacje monitoringu (Monitoring Locations)

- Drzewo lokalizacji: wybierz, które lokalizacje monitoringu wykonują tę kontrolę, według kontynentu, kraju albo całego świata; "Copy locations from another task" kopiuje zestaw lokalizacji z istniejącego monitora.
- Recheck strategy: jak zmiana stanu zostaje potwierdzona. Domyślnie głosowanie większościowe wśród lokalizacji ponownego sprawdzenia; alternatywy to konkretna liczba potwierdzających Down (suwak od 1 do 7, zgodnie z rozmiarem puli ponownego sprawdzenia), brak ponownego sprawdzenia w ogóle, pełna zgoda wszystkich lokalizacji ponownego sprawdzenia, albo pełna zgoda dla Down, podczas gdy Up wymaga tylko większości.
- If selected locations are unavailable: "Selected locations only" (domyślnie) czeka, aż wybrana lokalizacja wróci; "Closest locations" ponownie uruchamia kontrolę z najbliższych dostępnych lokalizacji; "Any location" korzysta z dowolnej dostępnej lokalizacji na świecie.
Przykład zastosowania
Monitorowanie przekaźnika pocztowego SMTPS na porcie 465: ustaw Url / Domain / IP na mail.example.com:465, włącz Connect over TLS/SSL, i włącz Require valid SSL certificate chain plus Require strong TLS protocol pod TLS Handshake, żeby wygasający albo obniżony certyfikat zaalertował Cię, zanim klienci zauważą odbite maile. Zostaw Response Pattern puste, chyba że usługa wysyła rozpoznawalny baner, który chcesz potwierdzać. Wybierz trzy lub cztery lokalizacje monitoringu rozproszone po regionach, zostaw domyślną strategię Recheck opartą na większości, zapisz kontakt zespołu operacyjnego na Down i Up z włączonym Repeat, i dodaj subskrypcję raportu Weekly dla cyklicznego podsumowania uptime.
Rozwiązywanie problemów
- Brak opcji UDP: mimo że podpowiedź przy Connect over TLS/SSL wspomina UDP, ten formularz zawsze otwiera połączenie TCP. Jeśli Twoja usługa docelowa jest tylko UDP, kontrola Port nie jest dziś właściwym narzędziem.
- Port osiągalny, ale kontrola wciąż zawodzi przy włączonym TLS: sprawdź przełączniki TLS Handshake po kolei. Certyfikat technicznie ważny, ale self-signed, albo serwer wciąż oferujący TLS 1.0/1.1, nie przejdzie odpowiednio Require valid SSL certificate chain albo Require strong TLS protocol, mimo że zwykłe połączenie by się powiodło.
- Response Pattern nigdy się nie dopasowuje: pamiętaj, że czytany jest tylko pierwszy 1 MB odpowiedzi. Wzorzec pojawiający się dopiero głęboko w długiej odpowiedzi, albo usługa wysyłająca duży ładunek przed tekstem, który dopasowujesz, nigdy się nie dopasuje - trzymaj wzorzec przy czymś, co usługa wysyła wcześnie.
- Port zablokowany na zaporze, nie w usłudze: kontrola, która zawodzi, mimo że usługa działa lokalnie bez zarzutu, to często reguła grupy bezpieczeństwa albo zapory blokująca ten konkretny port dla lokalizacji monitoringu HostTracker, a nie problem z usługą - potwierdź, że port jest otwarty na ruch z zewnątrz, nie tylko że proces działa.
- Expected IPs staje się nieaktualne po migracji: jeśli używasz Expected IPs Validation, a potem przenosisz usługę na nowy host albo IP, zaktualizuj listę - inaczej dostaniesz fałszywe Down, mimo że usługa jest osiągalna pod nowym adresem.
Powiązane
- Rozproszony monitoring dostępności - strona produktu obejmująca kontrole TCP Port.
- Darmowa kontrola portu - przetestuj parę host:port jednorazowo, natychmiast, bez tworzenia monitora.
- Kontrola Ping: pełny przewodnik konfiguracji - prostsza kontrola osiągalności, gdy nie musisz testować konkretnego portu ani usługi.
- Tryb assertów: pełny opis weryfikacji odpowiedzi - język reguł weryfikacji odpowiedzi używany w innych typach kontroli.
- Jak sprawdzić, czy port jest otwarty - jednorazowa wersja tej kontroli, plus polecenia
ncinmapstojące za nią. - Wszystkie przewodniki po monitoringu - przewodnik konfiguracji dla każdego innego typu kontroli.