NetMuteWas nsurlsessiond eigentlich ist
nsurlsessiond ist ein Systemdaemon, der mit macOS geliefert wird und von Apple signiert ist. Es ist der Hintergrund-Transfer-Agent für NSURLSession, die standardmäßige Netzwerk-API, die Anwendungen auf Apple-Plattformen verwenden, um mit Servern zu kommunizieren.
Der Name lässt sich klar aufschlüsseln, sobald du das weißt. NSURLSession ist die API, und das abschließende d ist die Unix-Konvention für einen Daemon, ein Hintergrundprozess ohne Fenster und ohne Dock-Icon. Er wird vom System gestartet, nicht von dir, und läuft, wann immer Arbeit für ihn ansteht.
Der wichtige Teil ist das Wort background. Wenn ein Entwickler NSURLSession verwendet, kann er einen Download oder Upload als Hintergrund-Transfer markieren, was dem System signalisiert, dass es auch unter Umständen weiterlaufen soll, die die App selbst nicht überleben würde: Der Nutzer schließt die App, die App wird ausgesetzt, die App stürzt ab oder der Mac bleibt allein. macOS respektiert das, indem es den Transfer an nsurlsessiond übergibt, der ihn ausführt und die App später benachrichtigt, sie bei Bedarf neu startet, um das Ergebnis zu liefern. Deshalb schreitet ein großer App Store-Download auch nach Schließen des App Store-Fensters weiter voran, und eine Podcast-Folge beendet das Herunterladen, obwohl du die Podcast-App nie wieder geöffnet hast.
Du wirst oft auch nsurlstoraged in der Nähe sehen. Es ist ein eng verwandter Apple-Daemon, der die Speicherung für URL-Session-Daten wie zwischengespeicherte Antworten und Cookies verwaltet, und es ist ebenso normal. Es zeigt in der Regel deutlich weniger Netzwerkaktivität, da seine Aufgabe auf der Speicherseite und nicht auf der Leitung liegt.
Warum sein Datenverkehr wirklich der anderer Apps ist
Das Wichtigste, was du über nsurlsessiond wissen musst, und warum so viele Menschen ihm misstrauen. Der Traffic, der nsurlsessiond zugeschrieben wird, gehört meist zu einer anderen App. Es ist ein gemeinsamer Kurier, der Pakete für jeden transportiert, der fragt, und die Pakete sind nicht an ihn adressiert.
Wenn Photos eine Reihe von Bildern in iCloud hochlädt, reisen die Bytes durch nsurlsessiond. Wenn der App Store ein Multi-Gigabyte-Update herunterzieht, ist es dasselbe. Wenn ein Drittanbieter-Client Dateien synchronisiert oder Medien vor-cacht, ist es sehr oft wieder dasselbe. All dieser Traffic wird von einem Prozess geöffnet, einem Prozess zugeschrieben und unter einem Namen angezeigt.
Activity Monitor und jedes Tool, das Traffic nur anhand des Besitzers des Sockets identifiziert, kann das nicht auflösen. Es zeigt, was auf Betriebssystemebene wahr ist: Die Verbindungen gehören zu nsurlsessiond. Was es nicht anzeigen kann, ist die anfragende App hinter jedem Transfer, weil diese Beziehung eine Ebene über dem Socket liegt. Das Ergebnis ist eine einzelne Zeile, die wie ein Prozess aussieht, der enorme Bandbreite verbraucht, obwohl es in Wirklichkeit die Arbeit mehrerer Apps unter einem Label ist.
Ein großer Anteil der nsurlsessiond-Alarmmeldungen ist also Fehlzuordnung, nicht Fehlverhalten. Wenn du dich fragst, warum ein Apple-Daemon vierzig Gigabyte Downloads benötigt, ist die Antwort, dass er sie nicht selbst gemacht hat. Etwas auf deinem Mac hat danach gefragt.
Das erklärt auch, warum der Daemon ständig zu laufen scheint. Er hält keine permanente Verbindung aufrecht. Er wacht auf, wenn eine Übertragung in die Warteschlange gestellt wird, erledigt die Arbeit und wird wieder ruhig. Auf einem Mac, der Fotos, Dokumente, Mail-Anhänge und App-Updates synchronisiert, ist fast immer etwas in der Warteschlange.
Ist nsurlsessiond sicher, und wie kannst du das selbst überprüfen
nsurlsessiond ist keine Malware. Es ist eine First-Party-Komponente von macOS, die auf jedem aktuellen Mac vorhanden ist, und es ist nicht notwendig, sie zu entfernen, zu deaktivieren oder mit einem Tool zu bereinigen.
Die vernünftige Vorsicht bei der Frage ist, dass Malware manchmal Namen annimmt, die Systemprozesse ähneln, in der Hoffnung, dass ein kurzer Blick in die Prozessliste sie passieren lässt. Zwei Checks im Terminal widerlegen das, und sie sind für jeden Prozess nützlich, nicht nur für diesen.
Der erste Check ist der Speicherort. Frage das System, wo die laufende Binärdatei liegt, mit dem Befehl pgrep und den Flags -lf, wobei du nsurlsessiond als Muster angibst. Der echte Daemon befindet sich in einem System-Framework-Pfad, tief im CFNetwork-Framework. Alles, was diesen Namen aus deinem Downloads-Ordner, deinem Home-Verzeichnis oder einem unbekannten Anwendungsbundle beansprucht, ist nicht der Apple-Daemon.
Der zweite Check ist die Code-Signatur, und er ist der stärkere der beiden, weil ein Pfad nachgeahmt werden kann, eine gültige Apple-Signatur jedoch nicht. Führe codesign mit den Flags -dv gegen den gefundenen Binärpfad aus. Der echte Daemon zeigt eine Vertrauenskette, die zu Apple gehört, mit Software Signing und der Apple Code Signing Certification Authority. Eine unsignierte Binärdatei oder eine, die von einem unbekannten Entwickler signiert wurde, sollte Anlass zur Sorge geben.
Wenn beide Checks bestehen, ist der Prozess, was er vorgibt zu sein, und jede Überraschung über sein Verhalten ist eine Frage der Apps, die Arbeit über ihn hineinreichen.
Hohe Netzwerknutzung oder hohe CPU: Was du prüfen solltest
Da nsurlsessiond nur im Auftrag von etwas anderem arbeitet, ist ungewöhnliche Aktivität von ihm ein Symptom, und die nützliche Diagnose liegt upstream. Eine kleine Anzahl von Ursachen macht den Großteil der Fälle aus.
Am häufigsten ist iCloud. Eine frisch aktivierte iCloud Photos-Bibliothek, ein wiederhergestellter Mac oder eine große Menge neuer Importe erzeugen anhaltenden Traffic, der je nach Bibliotheksgröße und Verbindungsgeschwindigkeit Stunden oder Tage dauern kann. iCloud Drive verhält sich ähnlich nach einer großen Ordneränderung. Danach folgt der App Store, inklusive großer App-Updates und Systemupdates, die im Hintergrund gestaged werden. Drittens sind Medien-Apps, die Inhalte vor-cachen, wie Podcast-Clients, die mehrere Episoden im Voraus ziehen.
Eine geordnete Vorgehensweise, von den günstigsten bis zu den aufwändigsten. Beginne mit den Kandidaten im Vordergrund: Öffne die App Store-Updates-Ansicht und die Systemeinstellungen, um zu sehen, ob ein Update heruntergeladen wird. Dann öffne Photos und lies die Statuszeile am unteren Rand der Bibliotheksansicht, die Synchronisationsfortschritt und Elementanzahl anzeigt, und prüfe iCloud Drive im Finder auf ausstehende Elemente. Überlege als Nächstes, was kürzlich installiert oder neu konfiguriert wurde, da ein neu hinzugefügter Sync-Client ein häufiger Auslöser ist. Lasse es schließlich laufen, weil Übertragungen mit definiertem Ende abgeschlossen werden.
Hohe CPU-Auslastung folgt meist den gleichen Ursachen, da anhaltende Übertragungen kontinuierliche Arbeit bedeuten, keine Leerlaufzeiten. Anhaltend hohe CPU-Auslastung ohne nennbaren Durchsatz ist weniger typisch und klärt sich oft durch einen Neustart, der den Daemon und seine Warteschlange zurücksetzt, ohne dauerhaften Effekt.
Was du vermeiden solltest, ist, es zu blockieren. Du kannst nsurlsessiond den Netzwerkzugang mit einer Firewall verweigern, was dazu führt, dass Hintergrundübertragungen im gesamten System aufhören, meist ohne Fehlermeldung. Downloads werden nie abgeschlossen, iCloud-bezogene Synchronisationen stocken, und Apps, die auf ihre Übertragungen angewiesen sind, stellen fest, dass sie nicht fertig werden. Da das Versagen still und systemweit ist, ist es eine schlechte Entscheidung. Der richtige Hebel ist die App, die die Arbeit in die Warteschlange stellt, nicht der Kurier, der sie transportiert.
Die App finden, die die Übertragung in die Warteschlange gestellt hat
Das wirft die Frage auf, die die integrierten Werkzeuge nicht beantworten können: Welches Programm hat tatsächlich all das angefragt. Activity Monitor endet an der Prozessgrenze, also zeigt die Zeile nsurlsessiond an und der Pfad endet dort.
Ein schärferer Ansatz ist, sich nicht auf Prozessnamen zu verlassen, sondern auf die Zielorte zu schauen. Die Verbindungen gehen immer noch irgendwohin, und diese Endpunkte identifizieren den Dienst hinter einer Übertragung, auch wenn der Prozessname das nicht tut. Apple Content Delivery und iCloud-Endpunkte sehen deutlich anders aus als ein Drittanbieter-Synchronisationsdienst oder ein Media-CDN, und sobald du die Domains sehen kannst, ist die Zuordnung kein Rätsel mehr.
Das ist die Lücke, um die NetMute gebaut wurde. Es zeigt den Echtzeit-Datenverkehr pro App und pro Prozess an, anstatt eine einzige Gesamtsumme, und kombiniert das mit domain-basiertem Logging, sodass du sehen kannst, welche Endpunkte eine Übertragung erreichen. Das verwandelt eine anonyme Zeile in ein klares Bild: wie viel geht zu iCloud, wie viel zu einer App, die du letzte Woche installiert hast.
Sobald du die Quelle kennst, bietet dir NetMute proportionale Möglichkeiten, darauf zu reagieren, und zwar auf die verantwortliche App, nicht auf den System-Daemon. Du kannst den Netzwerkzugang einer App mit einem Klick blockieren, temporäre Regeln setzen, die sich selbst auflösen, oder das Datenlimit einer App automatisch bei Erreichen des Caps sperren. Das ist ideal für Apps, die sich gut verhalten, bis sie entscheiden, eine Staffel von etwas vorzubereiten. Netzwerkprofile lassen diese Regeln je nach Kontext ändern, sodass ein Laptop an einem metered Hotspot Limits durchsetzen kann, die zu Hause nicht notwendig sind.
All das erfordert nicht, nsurlsessiond zu berühren. Der Daemon macht weiter seinen Job, Hintergrund-Downloads und iCloud-Transfers werden weiterhin abgeschlossen, und die App, die den Traffic erzeugt, ist diejenige, die eingeschränkt wird.
