Как проверить IP на блокировку в ТСПУ: рабочий Python-скрипт для диагностики

Практический Python-скрипт для проверки доступности IP или домена через DNS, TCP 443, TLS и HTTPS. Работает на Windows, Raspberry Pi, Rock Pi, Orange Pi, Debian, Ubuntu и Armbian без дополнительных библиотек.
⚠️ Дисклеймер: Материал опубликован исключительно в образовательных и исследовательских целях. Приведённые примеры предназначены для изучения принципов работы сетевых технологий, диагностики доступности собственных ресурсов и поиска технических неисправностей. Материал не предназначен для обхода установленных ограничений доступа и не содержит призыва к использованию средств обхода блокировок. Пользователь самостоятельно несёт ответственность за соблюдение законодательства Российской Федерации. Если вы попали сюда с конкретной задачей — сервер, сайт или IP внезапно перестал открываться и хочется понять, где именно ломается соединение — можно не читать полстатьи перед первым полезным действием.
⚡ Нужен быстрый результат без запуска скрипта? Я запустил отдельный онлайн-сервис: проверка сайта или IP на возможную блокировку ТСПУ / РКН. Просто укажите домен или IP — сервис выполнит диагностику и сразу покажет результат.
Также доступен отдельный проект roskompozor.ru, полностью посвящённый диагностике доступности сайтов и возможных ограничений со стороны ТСПУ. Его можно использовать как альтернативный вариант проверки.
Если нужна более подробная ручная диагностика и понимание того, на каком именно этапе ломается соединение, ниже в статье остаётся готовый Python-скрипт.
Ниже будет готовый Python-скрипт, который последовательно проверяет:
DNS
↓
TCP 443
↓
TLS
↓
HTTPS
А затем выполняет такую же проверку для контрольного узла.
В результате вместо бесполезного:
Не работает.
получаем что-то вроде:
DNS: OK
TCP 443: OK
TLS: ОШИБКА
И уже понятно, куда копать дальше.
Скрипт работает на:
- Raspberry Pi;
- Rock Pi;
- Orange Pi;
- Debian;
- Ubuntu;
- Armbian;
- Windows 10/11.
Дополнительные библиотеки не нужны. Всё работает на стандартном Python 3.
Важно: это инструмент диагностики сетевой доступности. Он не изменяет маршруты, не использует прокси, ничего не перенаправляет и не предназначен для обхода ограничений.
Если сначала хочется разобраться, почему сама фраза «IP заблокирован» не всегда технически корректна, отдельно есть статья Как работают ТСПУ Роскомнадзора: разбираемся вместе.
Если нужен только результат
На Linux, Raspberry Pi, Rock Pi или Orange Pi создаём файл:
nano ip_tspu_check.py
Вставляем скрипт из следующего раздела, сохраняем и запускаем:
python3 ip_tspu_check.py example.com
Если нужно проверить конкретный IP и вы знаете домен, который должен работать через него:
python3 ip_tspu_check.py 198.51.100.10 example.com
198.51.100.10 здесь приведён только как пример формата IP.
На Windows запуск практически такой же:
py ip_tspu_check.py example.com
Дальше смотрим на итоговый блок === Вывод ===.
Готовый Python-скрипт
Вот полностью рабочая версия:
#!/usr/bin/env python3
import ipaddress
import socket
import ssl
import sys
import time
from urllib.parse import urlparse
TIMEOUT = 4
PORT = 443
CONTROL_HOST = "ya.ru"
USER_AGENT = "v3trov-netcheck/2.0"
def normalize(value):
value = value.strip()
if "://" in value:
parsed = urlparse(value)
if parsed.hostname:
return parsed.hostname
return value.strip("[]")
def is_ip(value):
try:
ipaddress.ip_address(value)
return True
except ValueError:
return False
def ms(started):
return (
time.perf_counter() - started
) * 1000
def error_text(exc):
text = str(exc)
if (
isinstance(
exc,
(
socket.timeout,
TimeoutError,
),
)
or "timed out"
in text.lower()
):
return "таймаут"
return (
text
or exc.__class__.__name__
)
def host_for_http(value):
if (
not value
or is_ip(value)
):
return value
return (
value
.encode("idna")
.decode("ascii")
)
def check(
host,
sni=None,
port=PORT,
):
result = {
"host": host,
"sni": sni,
"port": port,
}
# Этап 1. DNS
if is_ip(host):
result["dns"] = (
"SKIP",
[host],
0,
None,
)
else:
started = (
time.perf_counter()
)
try:
infos = (
socket.getaddrinfo(
host,
port,
type=socket.SOCK_STREAM,
)
)
addresses = []
for info in infos:
address = (
info[4][0]
)
if (
address
not in addresses
):
addresses.append(
address
)
result["dns"] = (
"OK",
addresses,
ms(started),
None,
)
sni = host
result["sni"] = host
except socket.gaierror as exc:
result["dns"] = (
"FAIL",
[],
ms(started),
exc,
)
return result
# Этап 2. TCP
started = (
time.perf_counter()
)
try:
raw = (
socket.create_connection(
(host, port),
timeout=TIMEOUT,
)
)
raw.settimeout(
TIMEOUT
)
result["tcp"] = (
"OK",
ms(started),
raw.getpeername()[0],
None,
)
except OSError as exc:
result["tcp"] = (
"FAIL",
ms(started),
None,
exc,
)
return result
# Этап 3. TLS
#
# Проверка сертификата
# отключена намеренно:
# здесь проверяется сам
# TLS-handshake, а не
# доверие к сертификату.
context = ssl.SSLContext(
ssl.PROTOCOL_TLS_CLIENT
)
context.check_hostname = False
context.verify_mode = (
ssl.CERT_NONE
)
started = (
time.perf_counter()
)
try:
tls_sock = (
context.wrap_socket(
raw,
server_hostname=sni,
)
)
except (
OSError,
ssl.SSLError,
ValueError,
) as exc:
raw.close()
result["tls"] = (
"FAIL",
ms(started),
None,
exc,
)
return result
result["tls"] = (
"OK",
ms(started),
tls_sock.version(),
None,
)
# Этап 4. HTTPS
#
# Используем обычный GET,
# но читаем только начало
# HTTP-ответа.
# Страница целиком
# не скачивается.
started = (
time.perf_counter()
)
try:
with tls_sock:
http_host = (
host_for_http(
sni or host
)
)
request = (
"GET / HTTP/1.1rn"
f"Host: {http_host}rn"
f"User-Agent: {USER_AGENT}rn"
"Accept: */*rn"
"Connection: closern"
"rn"
).encode("ascii")
tls_sock.sendall(
request
)
data = b""
while (
b"rn"
not in data
and len(data) < 4096
):
chunk = (
tls_sock.recv(
1024
)
)
if not chunk:
break
data += chunk
status = (
data.split(
b"rn",
1,
)[0]
.decode(
"iso-8859-1",
errors="replace",
)
)
if status.startswith(
"HTTP/"
):
result["http"] = (
"OK",
ms(started),
status,
None,
)
else:
result["http"] = (
"FAIL",
ms(started),
status
or "нет HTTP-ответа",
None,
)
except (
OSError,
UnicodeError,
) as exc:
result["http"] = (
"FAIL",
ms(started),
None,
exc,
)
return result
def ok(
result,
stage,
):
value = result.get(
stage
)
return bool(
value
and value[0] == "OK"
)
def show(
title,
result,
):
print(
f"n=== {title} ==="
)
print(
f"Цель: "
f"{result['host']}:"
f"{result['port']}"
)
if (
result.get("sni")
and result["sni"]
!= result["host"]
):
print(
f"SNI/Host: "
f"{result['sni']}"
)
dns = result["dns"]
if dns[0] == "OK":
print(
f"DNS: OK, "
f"{dns[2]:.0f} мс -> "
+ ", ".join(
dns[1][:4]
)
)
elif dns[0] == "SKIP":
print(
"DNS: пропущен — "
"указан IP"
)
else:
print(
"DNS: ОШИБКА -> "
+ error_text(
dns[3]
)
)
return
tcp = result.get(
"tcp"
)
if not tcp:
return
if tcp[0] == "OK":
print(
f"TCP "
f"{result['port']}: "
f"OK, "
f"{tcp[1]:.0f} мс -> "
f"{tcp[2]}"
)
else:
print(
f"TCP "
f"{result['port']}: "
f"ОШИБКА, "
f"{tcp[1]:.0f} мс -> "
f"{error_text(tcp[3])}"
)
return
tls = result.get(
"tls"
)
if not tls:
return
if tls[0] == "OK":
print(
f"TLS: OK, "
f"{tls[1]:.0f} мс -> "
f"{tls[2]}"
)
else:
print(
f"TLS: ОШИБКА, "
f"{tls[1]:.0f} мс -> "
f"{error_text(tls[3])}"
)
return
http = result.get(
"http"
)
if not http:
return
if http[0] == "OK":
print(
f"HTTPS: OK, "
f"{http[1]:.0f} мс -> "
f"{http[2]}"
)
else:
details = (
http[2]
or error_text(
http[3]
)
)
print(
f"HTTPS: ОШИБКА, "
f"{http[1]:.0f} мс -> "
f"{details}"
)
def explain(
target,
control,
):
print(
"n=== Вывод ==="
)
if (
target["dns"][0]
== "FAIL"
):
print(
"Проблема начинается "
"уже на DNS. "
"До TCP/TLS проверка "
"не дошла."
)
return
if not ok(
target,
"tcp",
):
if ok(
control,
"tcp",
):
print(
"Контрольный узел "
"по TCP доступен, "
"а цель — нет. "
"Возможны закрытый "
"порт, firewall, "
"проблема маршрута "
"или промежуточная "
"фильтрация."
)
else:
print(
"TCP не работает "
"и у цели, и у "
"контрольного узла. "
"Сначала проверьте "
"интернет, роутер "
"и локальный firewall."
)
return
if not ok(
target,
"tls",
):
if (
is_ip(
target["host"]
)
and not target.get(
"sni"
)
):
print(
"TCP до IP работает, "
"но TLS не установился. "
"Для HTTPS это ещё "
"не признак блокировки: "
"серверу может "
"требоваться доменное "
"имя SNI."
)
else:
print(
"TCP работает, "
"но TLS-handshake "
"не проходит. "
"Проверьте SNI, "
"TLS-настройки сервера, "
"reverse proxy "
"и сетевой путь."
)
return
if ok(
target,
"http",
):
print(
"DNS/TCP/TLS/HTTPS "
"до цели работают "
"на базовом уровне. "
"На этих этапах "
"сетевого обрыва "
"не видно."
)
else:
print(
"TLS установился, "
"но нормальный "
"HTTP-ответ не получен. "
"Смотрите веб-сервер, "
"Host/SNI, reverse proxy "
"или приложение."
)
print(
"nВажно: один "
"клиентский тест "
"не доказывает причину "
"недоступности на 100%. "
"Он показывает этап, "
"на котором соединение "
"ломается."
)
def main():
if len(sys.argv) > 1:
target = normalize(
sys.argv[1]
)
else:
target = normalize(
input(
"Введите IP, "
"домен или URL: "
)
)
if not target:
print(
"Цель не указана."
)
sys.exit(2)
sni = None
if is_ip(target):
if len(sys.argv) > 2:
sni = normalize(
sys.argv[2]
)
else:
sni = normalize(
input(
"Домен этого IP "
"для TLS/SNI "
"(можно Enter): "
)
)
sni = sni or None
target_result = check(
target,
sni,
)
control_result = check(
CONTROL_HOST
)
show(
"Проверяемая цель",
target_result,
)
show(
"Контрольная проверка",
control_result,
)
explain(
target_result,
control_result,
)
print(
"nСкрипт выполняет "
"только обычные "
"диагностические "
"подключения и "
"не меняет маршрут "
"трафика."
)
if __name__ == "__main__":
main()
Что именно проверяет скрипт
Здесь важна последовательность.
Мы не пытаемся получить магический ответ:
ТСПУ: ДА
или:
ТСПУ: НЕТ
Такой вывод по одному клиентскому подключению был бы технически нечестным.
Вместо этого программа показывает точку отказа.
1. DNS
Если передан домен:
example.com
сначала выполняется обычное разрешение имени в IP.
Пример:
DNS: OK, 21 мс -> 93.x.x.x
Если DNS уже не работает, разбираться с TLS пока бессмысленно.
Проблема находится раньше:
домен
↓
DNS
↓
ОШИБКА
Если вводится непосредственно IP, проверка DNS пропускается.
2. TCP 443
Следующий этап — обычное TCP-соединение с портом 443.
Условно:
ваш компьютер
↓
TCP
↓
IP-адрес:443
Если видим:
TCP 443: OK
значит TCP-handshake состоялся.
Если:
TCP 443: ОШИБКА -> таймаут
причин может быть несколько:
- сервер выключен;
- порт
443закрыт; - firewall блокирует соединение;
- проблема маршрутизации;
- проблема на стороне провайдера;
- промежуточная фильтрация;
- ограничение доступа.
По одному таймауту определить конкретную причину нельзя.
Именно поэтому скрипт дополнительно проверяет контрольный узел.
Зачем нужен контрольный домен
Допустим, результат по интересующему серверу такой:
TCP 443: ОШИБКА -> таймаут
Сам по себе этот результат мало что говорит.
Вдруг у нас Wi-Fi отвалился, роутер задумался о вечном или провайдер решил провести технические работы ровно в этот момент.
Поэтому после основной цели скрипт автоматически проверяет:
ya.ru
Это не специальный адрес ТСПУ и не какой-то официальный эталон.
Просто контрольная точка.
Если получается:
=== Проверяемая цель ===
TCP 443: ОШИБКА -> таймаут
=== Контрольная проверка ===
TCP 443: OK
данных уже больше.
Мы знаем:
- интернет в целом работает;
- TCP 443 до контрольного узла устанавливается;
- до интересующего сервера TCP-соединение не проходит.
Причина всё ещё может находиться и на самом сервере, поэтому корректнее говорить о проблеме именно с этим сетевым направлением, а не сразу объявлять блокировку.
3. TLS
После успешного TCP-соединения выполняется обычный TLS-handshake.
Это тот этап, который происходит при открытии HTTPS-сайта ещё до получения самой страницы.
Нормальный результат:
TLS: OK, 82 мс -> TLSv1.3
Особенно интересна ситуация:
TCP 443: OK
TLS: ОШИБКА
TCP до сервера дошёл, а TLS уже не установился.
Тогда имеет смысл смотреть:
- SNI;
- TLS-конфигурацию;
- reverse proxy;
- настройки самого сервера;
- сетевое оборудование;
- поведение соединения по пути до сервера.
Но здесь есть один очень важный нюанс.
Почему при проверке IP нужен домен для SNI
Представим, что мы проверяем:
198.51.100.10
TCP работает:
TCP 443: OK
а TLS:
TLS: ОШИБКА
Это ещё вообще не значит, что IP фильтруется.
На одном IP сегодня вполне могут работать десятки или сотни HTTPS-сайтов.
При установлении TLS клиент передаёт имя сайта через SNI. По нему reverse proxy или веб-сервер понимает, какой виртуальный хост нужен.
Поэтому если известны одновременно IP и домен, лучше запускать так:
python3 ip_tspu_check.py 198.51.100.10 example.com
Тогда:
198.51.100.10
используется как адрес подключения, а:
example.com
передаётся как SNI и Host.
Это значительно полезнее проверки «голого» IP.
4. HTTPS
Если TLS успешно установился, программа отправляет обычный запрос:
GET / HTTP/1.1
Но страницу целиком не скачивает.
Скрипту нужна только первая строка HTTP-ответа:
HTTP/1.1 200 OK
или, например:
HTTP/1.1 301 Moved Permanently
Даже:
HTTP/1.1 403 Forbidden
для сетевой диагностики является полезным результатом.
Почему?
Потому что сервер ответил по HTTP.
То есть цепочка:
TCP
↓
TLS
↓
HTTPS
отработала до самого веб-сервера.
Как установить Python на Raspberry Pi, Rock Pi или Orange Pi
Проверяем:
python3 --version
Если получаем что-то вроде:
Python 3.11.2
ничего устанавливать не нужно.
Если Python отсутствует:
sudo apt update
sudo apt install -y python3
На Debian, Ubuntu и большинстве систем Armbian этого достаточно.
Если сам одноплатник ещё не настроен, можно сначала посмотреть Armbian: универсальная ОС для одноплатников — установка и настройка.
Для Rock Pi отдельно есть Rock Pi 4B: установка Armbian и подключение по SSH без монитора.
А если используется Raspberry Pi без экрана и клавиатуры — Headless Raspberry Pi: настройка без монитора через SSH.
Запуск на Linux и одноплатниках
Создаём файл:
nano ip_tspu_check.py
Вставляем код.
Сохраняем:
Ctrl+O
Enter
Ctrl+X
Запускаем:
python3 ip_tspu_check.py
Можно вводить цель интерактивно:
Введите IP, домен или URL:
Например:
example.com
Можно сразу передать домен:
python3 ip_tspu_check.py example.com
Можно даже вставить полный URL:
python3 ip_tspu_check.py https://example.com/test
Скрипт самостоятельно возьмёт из него имя хоста.
Для IP:
python3 ip_tspu_check.py 198.51.100.10
Если используется IP, программа спросит:
Домен этого IP для TLS/SNI (можно Enter):
Если домен известен — указываем.
Если нет — просто нажимаем Enter.
Запуск на Windows 10 и Windows 11
Проверяем Python:
py --version
Если команда py не работает:
python --version
Предположим, скрипт находится в:
C:netcheck
Переходим туда:
cd C:netcheck
Запускаем:
py ip_tspu_check.py
или сразу:
py ip_tspu_check.py example.com
Никакой WSL здесь не нужен.
Дополнительные Python-пакеты тоже не нужны.
То есть делать:
pip install ...
не требуется вообще.
Используются только стандартные модули:
socket;ssl;ipaddress;urllib.parse;time.
Как выглядит нормальный результат
Например:
=== Проверяемая цель ===
Цель: example.com:443
DNS: OK, 18 мс -> 93.x.x.x
TCP 443: OK, 61 мс -> 93.x.x.x
TLS: OK, 79 мс -> TLSv1.3
HTTPS: OK, 35 мс -> HTTP/1.1 200 OK
=== Контрольная проверка ===
Цель: ya.ru:443
DNS: OK, 12 мс -> 77.x.x.x
TCP 443: OK, 28 мс -> 77.x.x.x
TLS: OK, 41 мс -> TLSv1.3
HTTPS: OK, 24 мс -> HTTP/1.1 302 Found
=== Вывод ===
DNS/TCP/TLS/HTTPS до цели работают на базовом уровне.
На этих этапах сетевого обрыва не видно.
IP, задержки, версия TLS и HTTP-коды на реальном соединении будут другими.
Это нормально.
Как читать результат
Самый полезный блок здесь не цифры задержки, а последовательность состояний.
| Результат | Что это обычно означает |
|---|---|
DNS: ОШИБКА |
проблема начинается с разрешения домена |
DNS: OK, TCP: ОШИБКА |
до TCP-порта цели соединение не устанавливается |
TCP: OK, TLS: ОШИБКА |
TCP работает, проблема начинается на TLS |
TLS: OK, HTTPS: ОШИБКА |
сеть и TLS уже работают, смотрим веб-сервер или приложение |
Всё OK |
базовая HTTPS-цепочка до сервера работает |
Теперь чуть подробнее.
Вариант: DNS не работает
Например:
DNS: ОШИБКА -> Name or service not known
До подключения к серверу программа даже не дошла.
Проверяем:
- правильно ли написан домен;
- существует ли DNS-запись;
- какой DNS используется на компьютере;
- DNS на роутере;
- состояние подключения к интернету.
Говорить о блокировке IP здесь вообще рано — IP ещё даже не был получен.
Вариант: контроль работает, а TCP до цели нет
Например:
=== Проверяемая цель ===
TCP 443: ОШИБКА, 4003 мс -> таймаут
=== Контрольная проверка ===
TCP 443: OK, 31 мс
Вот это уже полезный результат.
Мы понимаем, что TCP в интернет в принципе работает.
Но конкретное направление не отвечает.
Причиной могут быть:
- выключенный сервер;
- закрытый
443; nftables;iptables;firewalld;- security group у VPS-провайдера;
- ошибка маршрутизации;
- проблема на промежуточном оборудовании;
- фильтрация трафика.
То есть проблема локализована, но её источник пока не доказан.
Вариант: TCP работает, а TLS нет
TCP 443: OK
TLS: ОШИБКА -> таймаут
Это уже другой класс проблемы.
До TCP-порта мы дошли.
Значит сервер или устройство перед ним приняло TCP-соединение.
Дальше не завершился TLS-handshake.
Если проверяется домен, смотрим:
- SNI;
- TLS;
- сертификатную/TLS-конфигурацию сервера;
- reverse proxy;
- балансировщик;
- сетевой путь.
Если проверяется IP без SNI, сначала желательно повторить тест с доменным именем.
Вариант: TLS работает, а HTTPS нет
TCP 443: OK
TLS: OK
HTTPS: ОШИБКА
Здесь сеть уже довела нас очень далеко.
TCP работает.
TLS работает.
Проблема начинается после отправки HTTP-запроса.
В первую очередь смотрим:
- nginx;
- Apache;
- reverse proxy;
- приложение;
- виртуальный хост;
Host;- конфигурацию upstream.
Если перед сервером стоит Nginx Proxy Manager, можно свериться с отдельной инструкцией Nginx Proxy Manager: установка и первоначальная настройка reverse proxy с HTTPS в Docker.
Почему обычного ping недостаточно
Потому что ping и HTTPS проверяют разные вещи.
ping работает через ICMP.
HTTPS условно выглядит так:
DNS
↓
TCP
↓
TLS
↓
HTTP
Поэтому совершенно нормальна ситуация:
PING: OK
TCP 443: FAIL
IP отвечает на ICMP, но веб-сервис недоступен.
Бывает и наоборот:
PING: FAIL
HTTPS: OK
Некоторые серверы или firewall просто не отвечают на ICMP.
Для проверки сайта или HTTPS-сервиса гораздо интереснее реальное подключение к TCP 443.
Можно ли по результату точно сказать «это ТСПУ»
Нет.
И именно поэтому в скрипте намеренно нет строки:
ТСПУ ОБНАРУЖЕНО
Представим:
Контроль:
TCP 443 -> OK
Цель:
TCP 443 -> TIMEOUT
Такая картина действительно может возникнуть при промежуточной фильтрации.
Но точно такую же картину легко создаст firewall на самом сервере.
Например:
nftables
iptables
firewalld
То же самое получится, если 443 просто закрыт.
Поэтому технически корректный вывод звучит примерно так:
Контрольное соединение работает, а до конкретной цели TCP-соединение не устанавливается.
Это факт.
А вот причина уже требует дальнейшей проверки.
Как сделать диагностику убедительнее
Если проверяется ваш собственный сервер или сервис, полезно выполнить один и тот же тест из нескольких обычных подключений.
Например:
- домашний интернет;
- мобильная сеть;
- другой провайдер;
- непосредственно сам сервер.
Если сервис:
из сети A -> работает
из сети B -> стабильно ломается на TLS
это уже гораздо информативнее одного запуска.
Но даже здесь лучше фиксировать наблюдаемое поведение, а не пытаться превратить сетевую диагностику в гадание по одному таймауту.
Можно ли держать скрипт на Raspberry Pi или Rock Pi постоянно
Да.
Он почти ничего не требует от железа.
Файл можно положить, например, сюда:
/home/user/ip_tspu_check.py
И запускать, когда нужно:
python3 /home/user/ip_tspu_check.py server.example.com
Для такой задачи даже старого одноплатника более чем достаточно.
Поэтому маленький Raspberry Pi, Rock Pi или Orange Pi вполне может стать отдельной диагностической точкой в домашней сети.
Особенно полезно для проверки своего сервера
Допустим, есть VPS или домашний сервер:
IP: 198.51.100.10
Domain: server.example.com
Запускаем:
python3 ip_tspu_check.py 198.51.100.10 server.example.com
Через несколько секунд получаем четыре отдельных этапа:
DNS
TCP
TLS
HTTPS
Если TCP не устанавливается — смотрим сеть, firewall и доступность порта.
Если TCP есть, но TLS не проходит — смотрим TLS/SNI и reverse proxy.
Если TLS работает, а HTTP-ответа нет — смотрим nginx, Apache или приложение.
Это заметно полезнее, чем десять раз запустить ping, увидеть ответы и продолжать гадать, почему браузер всё равно ничего не открывает.
Что в итоге
Проверить IP на блокировку в ТСПУ одной командой со стопроцентной достоверностью нельзя.
Но можно решить более практичную задачу: понять, на каком этапе перестаёт работать соединение.
Этот скрипт последовательно проверяет:
DNS
↓
TCP 443
↓
TLS
↓
HTTPS
и сравнивает результат с контрольным узлом.
В большинстве случаев этого уже достаточно, чтобы отделить:
- проблему DNS;
- закрытый TCP-порт;
- firewall;
- проблему TLS/SNI;
- ошибку reverse proxy;
- проблему веб-сервера;
- общую проблему интернета;
- ситуацию, похожую на промежуточную сетевую фильтрацию.
При этом программа ничего не перенастраивает и не вмешивается в маршрутизацию — она просто делает обычные сетевые подключения и показывает, где именно цепочка перестала работать.
Понравилась статья?
Поставьте лайк и сохраните полезный материал в закладки.
Посетители, находящиеся в группе Гости, не могут оставлять комментарии к данной публикации.
Nginx Proxy Manager: установка и первоначальная настройка reverse proxy с HTTPS в Docker
Routerich AX3000: настройка роутера на OpenWrt, Mesh, TorrServer и сетевое хранилище
Как работают ТСПУ Роскомнадзора? Разбираемся вместе
VPN только для выбранных сайтов и устройств в OpenWrt: раздельная маршрутизация трафика
ZeroBlock для OpenWrt: настройка VPN и маршрутизации на Routerich
Как создать своего бота в MAX: регистрация, API и примеры использования