NetMuteЧто такое на самом деле cloudd
cloudd, это демон CloudKit: процесс, который macOS использует для связи с серверами iCloud Apple от имени приложений. Это стандартная часть macOS, поставляется Apple и подписан кодом Apple, это не вредоносное ПО.
CloudKit, это фреймворк Apple для хранения данных приложений в iCloud и поддержания их согласованности между устройствами пользователя. Приложения не открывают собственные соединения для синхронизации, они передают данные в CloudKit, а cloudd занимается загрузкой изменений, получением изменений, сделанных на других устройствах, и повторными попытками при сбоях.
На него завязано больше, чем многие думают. Синхронизация документов iCloud Drive проходит через него, как и Notes, а Photos использует его для метаданных медиатеки. Многие приложения Apple сами опираются на него, чтобы оставаться согласованными на Mac, iPhone и iPad, и так же поступает множество сторонних приложений: CloudKit, популярная основа для синхронизации, потому что разработчику не нужен собственный сервер.
Так что когда cloudd активен, вы почти всегда видите синхронизацию iCloud, для системы, для приложения Apple или для того, что вы установили.
Почему трафик cloudd на самом деле является трафиком других приложений
Это самое полезное, что нужно понимать о cloudd, и источник почти всей путаницы вокруг него.
cloudd это общий курьер. Он не создает трафик сам по себе в каком-либо значимом смысле, он переносит данные других приложений. Когда меняется заметка, когда документ попадает в iCloud Drive, когда сторонний менеджер задач синхронизирует элемент, эти байты покидают ваш Mac под именем cloudd, а не под именем приложения, которое их создало. Любой инструмент, который приписывает сетевую активность по процессам, включая Activity Monitor, поэтому покажет большую цифру у cloudd и меньшую у приложений, которые действительно за это отвечают.
Так что большой объем данных у cloudd редко говорит о самом cloudd. Он говорит о том, сколько синхронизируют ваши приложения, и все это сводится в одну строку. Два Mac с одинаковыми копиями macOS могут показывать совершенно разные значения cloudd просто потому, что на одном большая библиотека Photos и несколько приложений на базе CloudKit.
macOS делает так и в других местах: nsurlsessiond переносит фоновые загрузки и выгрузки для других приложений и выглядит тяжелым по той же причине. Как только вы замечаете этот шаблон, занятый демон с общим именем перестает пугать. Обычно это всего лишь труба, и интересный вопрос в том, что через нее проталкивается.
Является ли cloudd безопасным и как проверить это самостоятельно
cloudd безопасен. Это демон Apple первого уровня, он уже много лет является частью macOS, и его поведение полностью объясняется той работой, которую он выполняет. Разумный вопрос здесь не в том, опасен ли настоящий cloudd, а в том, является ли процесс с этим именем на вашем Mac настоящим. Вопрос справедливый, потому что взять скучное имя, похожее на системное, это старый приём.
Проверить это можно без специальных инструментов. В Activity Monitor найдите cloudd и откройте инспектор двойным щелчком. Настоящий демон находится в системном томе только для чтения, а не в вашей домашней папке, Applications или Downloads, и запускает его launchd, а не что-то, что вы открыли сами. Процесс cloudd, работающий из пользовательского каталога, был бы аномалией, за которой стоит последить.
Более надёжная проверка, это кодовая подпись. Системные бинарные файлы Apple подписаны Apple, а в современных версиях macOS системный том криптографически запечатан, так что подменить системный демон обычная программа тихо не сможет. В macOS есть командная строка с утилитами, которые показывают издателя подписи любого бинарного файла, и для cloudd там должна быть Apple.
И ещё стоит сказать, чем cloudd не является. Это не процесс аналитики или телеметрии, он переносит данные ваших приложений в iCloud и из iCloud для уже включённых вами служб.
Почему cloudd использует так много CPU или сети
Высокая активность cloudd почти всегда означает, что идет крупная синхронизация, и самый частый случай, это начальная синхронизация. Недавно вошедшая учетная запись iCloud, свежая установка или только что включенный сервис должны сверить все с нуля, и это может длиться часами и передавать очень много данных. Классический пример, большая библиотека Photos, как и большая папка iCloud Drive, которую только что добавили или восстановили. Правильная реакция обычно простая, терпение: дайте процессу завершиться на соединении, где трафик не важен, и активность сама спадет до редких всплесков.
Вторая причина, это синхронизация, которая постоянно срывается и повторяется. Если элемент не удается загрузить, cloudd может зациклить попытки, и это выглядит как постоянная нагрузка CPU без видимого результата. Признак, активность, которая не утихает, идет днями, а не часами, и при этом нет большого переноса данных, который все объяснил бы. Перезапуск решает многие такие случаи, а если нет, обычно помогает выключить и снова включить затронутый сервис в настройках iCloud, либо выйти из iCloud и войти снова.
В-третьих, проверьте, что именно включено. В настройках iCloud видно, какие сервисы и приложения синхронизируются, включая сторонние, и отключение синхронизации для приложения, которым вы редко пользуетесь, полностью убирает его нагрузку.
На тарифном подключении проблема не в том, что cloudd занят, а в том, что его активность стоит денег. Но ответ все равно не в том, чтобы блокировать его: приостановите синхронизацию iCloud, включите Low Data Mode для этой сети, отключите самые тяжелые сервисы, пока находитесь в ней, или ограничьте трафик.
Блокировка этого и общая картина
Блокировать cloudd с помощью брандмауэра возможно, и это плохая идея по одной конкретной причине: это ломает синхронизацию iCloud по всей системе и делает это тихо. Ошибки не показываются. Заметки перестают появляться на других устройствах, документы перестают обновляться, сторонние приложения тихо устаревают, и через недели вы начинаете понимать, почему изменение, сделанное на вашем Mac, никогда не дошло до вашего iPhone. Механизм не то, на что нужно нападать, а объём.
Что остаётся настоящей проблемой: видимость. macOS запускает множество демонов, которые общаются с сетью без запроса, многие имеют имена, которые ничего не раскрывают, и система практически не даёт способов увидеть, кто куда подключается и сколько данных передаётся. Когда один из них поднимается в верхнюю часть списка по использованию пропускной способности, нет встроенного способа понять, нормально ли это.
Этот пробел закрывает NetMute. Он показывает трафик в реальном времени для каждого приложения и процесса, а логирование на уровне доменов фиксирует, с какими доменами связывался каждый процесс и сколько данных передавалось. Для тарифицируемого случая практическим инструментом являются лимиты данных для каждого приложения: суточный или месячный лимит на процесс, предупреждение при достижении выбранного порога и автоматическая блокировка при 100 процентах, с глобальным лимитом сверху и лимитами, сохранёнными для каждого сетевого профиля, чтобы правила для точки доступа не были вашими домашними правилами. Профили переключаются автоматически при подключении к Wi-Fi, а per-app firewall блокирует всё, что не должно общаться, одним кликом, с временными правилами для тестирования, которые автоматически истекают.
Цель не в том, чтобы блокировать больше. Как показывает cloudd, большая часть фонового трафика на Mac является легитимной. Цель в том, чтобы уметь отличать её и держать в рамках бюджета, когда соединение, которым вы пользуетесь, имеет лимит.
