Ошибка «Error in TightVNC Viewer: подключение не установлено, т.к. конечный компьютер отверг запрос на подключение» означает, что клиент успешно нашёл удалённый компьютер по сети, но TCP-соединение на указанный порт было активно отклонено. Это принципиально отличает её от ошибок таймаута: сеть работает, пакеты доходят, но на целевой машине никто не «слушает» порт VNC — либо его блокирует фильтр на самом хосте.
Чаще всего виноваты не запущенный сервис TightVNC Server, неверный порт (по умолчанию 5900), правила брандмауэра Windows или антивирус с сетевым экраном. Ниже разберём диагностику по шагам — от простых проверок до тонких настроек, чтобы вы могли быстро восстановить удалённый доступ.
Что означает эта ошибка на техническом уровне
Сообщение об отказе в подключении (connection refused) формируется, когда операционная система целевого компьютера отвечает на SYN-пакет сбросом соединения. Это происходит в двух случаях: на порту нет прослушивающего процесса либо входящее соединение отклоняет фильтр, настроенный в режиме «отклонить», а не «отбросить молча».
Ключевой вывод из этого простой: проблема почти всегда на стороне сервера (того компьютера, к которому вы подключаетесь), а не клиента. Переустановка TightVNC Viewer на вашей машине, как правило, ничего не даст — искать причину нужно на удалённом ПК.
Шаг 1. Проверьте, запущен ли TightVNC Server
Самая частая причина — служба VNC-сервера просто не работает. На удалённом компьютере откройте оснастку служб командой services.msc (Win+R) и найдите службу TightVNC Server (может называться tvnserver). Проверьте её состояние: она должна быть в статусе «Выполняется», а тип запуска желательно установить в «Автоматически».
Если служба остановлена — запустите её и повторите подключение. Если службы в списке нет вообще, возможно, TightVNC был установлен только в режиме приложения: тогда сервер запускается вручную через ярлык Launch TightVNC Service из меню «Пуск» либо командой:
"C:\Program Files\TightVNC\tvnserver.exe" -controlservice -start⚠️ Внимание: если TightVNC запущен как обычное приложение (application mode), оно работает только до выхода пользователя из системы. После перезагрузки или смены сессии подключение снова будет отклонено — для постоянного доступа используйте режим службы.
Шаг 2. Убедитесь, что порт 5900 прослушивается
Даже при запущенной службе стоит проверить, что сервер реально прослушивает нужный порт. На удалённой машине выполните в командной строке:
netstat -ano | findstr :5900В выводе должна быть строка с состоянием LISTENING. Если её нет — сервер либо не запущен, либо настроен на другой порт. Порт можно проверить в настройках сервера: двойной клик по значку TightVNC в системном трее → вкладка Server → поля Main server port (обычно 5900) и HTTP port (обычно 5800).
Обратите внимание: если в адресе подключения вы указываете порт вручную, в TightVNC Viewer используется формат 192.168.1.50::5900 (двойное двоеточие) или просто номер дисплея через одинарное двоеточие (192.168.1.50:0, где 0 соответствует порту 5900). Ошибка в формате адреса — тоже частая причина отказа.
☑️ Быстрая диагностика TightVNC
Шаг 3. Настройте брандмауэр Windows
Встроенный брандмауэр — второй по частоте источник проблемы. При установке TightVNC обычно предлагает создать правило автоматически, но если вы отказались или правило было удалено, входящие подключения на порт 5900 будут отклоняться.
- 🔥 Откройте
Панель управления → Брандмауэр Защитника Windows → Дополнительные параметры. - 📥 Создайте правило для входящих подключений: тип «Для порта», протокол TCP, порт
5900, действие «Разрешить подключение». - 🖥️ Альтернатива — правило для программы: укажите путь к
tvnserver.exeв папке установки TightVNC. - 🌐 Проверьте профиль сети: правило должно действовать для того профиля (частный/доменный/публичный), который активен на сетевом интерфейсе.
Быстрый способ создать правило — одна команда в командной строке от имени администратора:
netsh advfirewall firewall add rule name="TightVNC 5900" dir=in action=allow protocol=TCP localport=5900Шаг 4. Антивирус и сторонние сетевые экраны
Многие антивирусные пакеты включают собственный сетевой экран, который работает параллельно с брандмауэром Windows или вместо него. Даже при корректном правиле в брандмауэре сторонний файрвол может молча блокировать tvnserver.exe.
Проверьте журнал блокировок вашего антивируса и добавьте исполняемый файл сервера в исключения сетевого экрана. Для быстрой диагностики можно временно отключить сетевой экран антивируса на пару минут и повторить подключение: если ошибка исчезла — причина найдена, остаётся лишь создать постоянное разрешающее правило и снова включить защиту.
Шаг 5. Проверка сетевой доступности и адреса
Хотя «отказ в подключении» обычно означает, что маршрут до хоста есть, стоит убедиться, что вы подключаетесь к правильному адресу. Выполните с клиентской машины ping 192.168.1.50 (подставьте IP удалённого ПК) и сверьте адрес с выводом ipconfig на сервере — в сетях с DHCP адрес мог измениться после перезагрузки роутера.
Дополнительно проверьте доступность порта напрямую через PowerShell с клиентской машины:
Test-NetConnection 192.168.1.50 -Port 5900Если TcpTestSucceeded возвращает False при работающем сервере и открытом брандмауэре — ищите фильтрацию на промежуточном оборудовании: роутере, точке доступа или в гостевой изоляции Wi-Fi (функция AP isolation запрещает обмен трафиком между клиентами беспроводной сети).
| Проверка | Команда / действие | Ожидаемый результат |
|---|---|---|
| Служба сервера | services.msc → TightVNC Server | Статус «Выполняется» |
| Прослушивание порта | netstat -ano | findstr :5900 | Строка с LISTENING |
| Доступность хоста | ping <IP> | Ответы без потерь |
| Доступность порта | Test-NetConnection <IP> -Port 5900 | TcpTestSucceeded: True |
| Правило брандмауэра | Доп. параметры брандмауэра | Разрешающее правило TCP 5900 |
Другие возможные причины
Если базовые шаги не помогли, рассмотрите менее очевидные сценарии. Возможная причина — конфликт порта: другая программа уже заняла 5900, и сервер TightVNC не смог его открыть. Проверить это поможет тот же netstat -ano: по PID процесса в последнем столбце через Диспетчер задач определите, кому принадлежит порт.
- 🔑 Пустой пароль: если в настройках сервера не задан primary password, некоторые версии сервера могут отклонять входящие соединения — задайте пароль в настройках.
- 🚫 Ограничение по IP: в настройках TightVNC Server есть вкладка Access Control, где можно разрешать или запрещать подключения по диапазонам адресов — проверьте, что ваш IP не попал в блокировку.
- 🔄 Повреждённая установка: переустановите TightVNC той же или актуальной версии, при установке отметьте регистрацию службы.
- 👥 Сессия пользователя: в редких конфигурациях сервер, запущенный в application mode, недоступен на экране входа в систему — используйте режим службы.
⚠️ Внимание: открывая VNC-доступ за пределы локальной сети (через проброс портов на роутере), вы подвергаете компьютер риску — протокол VNC имеет ограниченную защиту. Для доступа через интернет безопаснее использовать VPN-туннель, а порт 5900 наружу не публиковать.
Как сменить порт TightVNC, если 5900 занят
Откройте настройки сервера (значок в трее → Configuration), на вкладке Server измените Main server port, например на 5901. Перезапустите службу, создайте правило брандмауэра для нового порта и подключайтесь с указанием адреса вида 192.168.1.50::5901.
Когда ничего не помогло
Если после всех проверок подключение по-прежнему отклоняется, соберите диагностику системно: журнал TightVNC Server (включается в настройках, раздел логирования), журналы брандмауэра Windows и события системы. Часто в логах видно, на каком этапе обрывается соединение.
Как временную альтернативу можно проверить подключение другим VNC-клиентом или другим средством удалённого доступа (например, встроенным RDP, если редакция Windows его поддерживает). Это поможет понять, проблема в конкретной связке TightVNC или в сетевой конфигурации в целом.
Частые вопросы (FAQ)
Почему TightVNC пишет «подключение не установлено», хотя компьютер пингуется?
Ping проверяет только доступность хоста по протоколу ICMP, а VNC использует TCP-порт 5900. Хост может отвечать на ping, но отклонять соединение, если служба сервера не запущена или порт закрыт брандмауэром.
Какой порт использует TightVNC по умолчанию?
Основной порт сервера — 5900 (TCP), дополнительный HTTP-порт для доступа через браузер — 5800. Оба значения можно изменить в настройках сервера на вкладке Server.
Нужно ли открывать порт в брандмауэре на клиенте?
Нет. Исходящие подключения в брандмауэре Windows обычно разрешены, поэтому правила нужны только на стороне сервера — для входящего трафика на порт VNC.
Ошибка появляется только после перезагрузки удалённого ПК. Что делать?
Проверьте, что TightVNC работает в режиме службы с автоматическим запуском, а не как приложение вручную. В services.msc для службы TightVNC Server установите тип запуска «Автоматически».
Может ли быть причиной неверный пароль?
Нет. При неверном пароле соединение устанавливается, а затем отклоняется уже на этапе аутентификации с соответствующим сообщением. Ошибка «конечный компьютер отверг запрос на подключение» возникает раньше — на этапе TCP-подключения, до проверки пароля.