Cloud-Mac-Supportcenter

Fehler zuerst eingrenzen, dann diagnostische Informationen senden

Keine Verbindung, fehlgeschlagener Build oder wartender Runner? Nicht gleich die Umgebung neu installieren. Prüfen Sie zuerst Bestellung, Netzwerk, System und Toolchain und senden Sie anschließend die wichtigsten Logs an den Support.

VNC, SSH, Xcode und CI/CD getrennt diagnostizieren
Bestellnummer, Knoten, Zeitpunkt und vollständigen Fehlerkontext angeben
Schlüssel, Token und Signaturpasswörter aus Logs entfernen

Cloud-Mac jetzt mieten Im Portal ein Ticket erstellen

Diagnose-Ticket BUILD-SUPPORT

Fehleranalyse vorbereiten

Bereitstellungsstatus bestätigen Bestellung, Knotenadresse und Zugangsdaten müssen zusammenpassen

Grundlage

Verbindungswege unterscheiden VNC, SSH und lokales Netzwerk getrennt testen

Netzwerk

Build-Variablen eingrenzen Scheme, Xcode-Version und Abhängigkeiten festlegen

Tools

Fehlerkontext bewahren Zeitpunkt, Befehl, Logs und ausgeführte Schritte dokumentieren

Nachweise

Ziel: reproduzierbare, lokalisierbare und weiter bearbeitbare Probleme 4 Diagnoseebenen

Nach Problemtyp einsteigen

Sechs Support-Einstiege für sechs Prüfanfänge

Ordnen Sie das Problem Verbindung, Build, Automatisierung, Netzwerk, Speicher oder Abrechnung zu. Eine korrekte Einordnung reduziert das Wechseln zwischen verschiedenen Logs.

Remotezugriff

VNC-Bildschirm und Sitzung

Beheben Sie schwarzen Bildschirm, Timeouts, Tastaturbelegung, Zwischenablage und Sitzungsabbrüche. Halten Sie zuerst Clientname, Netzwerk und Zeitpunkt fest.

Xcode-Build

Signierung, Abhängigkeiten und Archivierung

Prüfen Sie Zertifikate, Provisioning-Profile, Keychain-Berechtigungen, DerivedData, Dependency-Cache, freien Speicher und Exportkonfiguration.

CI/CD

Runner-Warteschlange und Arbeitsverzeichnis

Prüfen Sie Label-Zuordnung, Dienstprozess, Projektberechtigungen, Parallelität, Rechte des Arbeitsverzeichnisses und die Bereinigung nach fehlgeschlagenen Jobs.

Netzwerk

Repository, Abhängigkeitsquellen und Remotezugriff

Unterscheiden Sie lokales Netzwerk, Ausgang des Knotens, Code-Repository und Downloadquelle für Abhängigkeiten, damit ein einzelner Timeout nicht als vollständiger Offline-Status gilt.

Speichererweiterung

Kapazität prüfen und Erweiterung anfragen

Ermitteln Sie zunächst den Speicherbedarf von Projekten, DerivedData, Dependency-Cache, Archiven und Modelldateien. Fragen Sie anschließend +1 TB, +2 TB SSD oder Parallelbetrieb an.

Abrechnung

Laufzeit, Zusatzoptionen und Zahlungsdaten

Geben Sie Bestellnummer, Abrechnungszeitraum, Zahlungsart und Seitenhinweis an. Vollständige Zahlungsdaten oder vertrauliche Informationen gehören nicht in öffentliche E-Mails.

Schnellcheck in sieben Schritten

Erst Erreichbarkeit prüfen, dann die Toolchain

Arbeiten Sie die Schritte der Reihe nach ab. Ohne Bestätigung des vorherigen Schritts sollten Sie weder Cache löschen noch Abhängigkeiten neu installieren, da sonst wichtige Fehlerhinweise verloren gehen.

01

Bestellstatus prüfen

Melden Sie sich im Portal an und bestätigen Sie die Bereitstellung. Modell, Laufzeit und Knoten müssen zum geprüften Objekt passen. Bei Abweichungen zuerst Bestellnummer und Seitenhinweis notieren.

Bestellung
02

Knotenadresse prüfen

Stellen Sie sicher, dass VNC und SSH die Adresse und den Port aus den Bereitstellungsdaten verwenden. Keine alten Knoten, Lesezeichen oder Verbindungsdaten anderer Bestellungen verwenden.

Adressierung
03

Kontozugangsdaten bestätigen

Prüfen Sie Benutzername, Passwort und Groß-/Kleinschreibung der Tastatur. Passwörter, private Schlüssel oder Wiederherstellungsdaten nicht in den Tickettext einfügen.

Zugriff
04

VNC-Client gegenprüfen

Notieren Sie Clientname, Version und Bildqualität. Wenn möglich, mit einem anderen lokalen Gerät oder Netzwerk erneut testen, um Clientprobleme abzugrenzen.

Desktop
05

SSH-Konnektivität testen

Dokumentieren Sie, ob DNS-Auflösung, Verbindungsaufbau oder Authentifizierung fehlschlägt. Wenn VNC ausfällt, SSH aber funktioniert, zuerst die grafische Sitzung statt das gesamte Netzwerk prüfen.

Netzwerk
06

Festplattenspeicher prüfen

Achten Sie auf den freien Systemplattenspeicher sowie DerivedData, Abhängigkeitsverzeichnisse, Archive, Simulatoren und Modelldateien. Zu wenig Speicher verursacht oft schwer erkennbare Buildfehler.

Ressourcen
07

Xcode-Version festlegen

Notieren Sie den tatsächlich ausgewählten Xcode-Pfad und die Version. CI-Skript und interaktiver Build müssen dieselbe Toolchain verwenden; anschließend den fehlgeschlagenen Befehl erneut ausführen.

Tools

Fehlerbehebung beim Remotezugriff

Bildschirm-, Netzwerk- und Eingabeprobleme getrennt prüfen

VNC stellt die grafische Sitzung bereit, SSH den Kommandozeilenpfad. Separate Tests zeigen schnell, ob Client, Netzwerkverbindung oder Knotensitzung betroffen ist.

Häufige Remotezugriffsprobleme, erste Prüfungen und Ticketdaten
Erscheinung	Erster Schritt	Zu dokumentieren	Vermeiden
Schwarzer VNC-Bildschirm	Warten Sie die Sitzungsinitialisierung ab, bauen Sie die Verbindung einmal neu auf und prüfen Sie, ob SSH normal antwortet.	Clientname, Zeitpunkt, Knoten, SSH-Testergebnis und Screenshot des schwarzen Bildschirms.	Nicht wiederholt zwangsweise verbinden und nicht sofort System- oder Benutzerkonfigurationen löschen.
Verbindungs-Timeout	Lokales Netzwerk wechseln, Adresse und Port prüfen und DNS- von Authentifizierungs-Timeout unterscheiden.	Lokaler Netzwerktyp, Originalfehler, Start- und Fehlerzeitpunkt sowie Ergebnis des Tests über ein anderes Netzwerk.	Passwort, privaten Schlüssel oder vollständige Authentifizierungsdaten nicht in Logs veröffentlichen.
Fehlerhafte Tastaturbelegung	Lokale und entfernte Tastaturbelegung, Eingabemethode und Modifier-Zuordnung prüfen; in einem Nur-Text-Editor testen.	Client, Tastaturbelegung, fehlerhafte Tasten und reproduzierbare Schritte.	Nicht nur IDE-Tastenkürzel testen; zuerst anwendungsspezifische Tastenbelegung ausschließen.
Zwischenablage nicht verfügbar	Bestätigen Sie, dass der Client die Zwischenablage synchronisieren darf, und testen Sie Nur-Text sowie kurze Inhalte getrennt.	Kopierrichtung, Inhaltstyp, Clientversion und ob alle Anwendungen betroffen sind.	Keine Schlüssel, Token oder Signaturpasswörter als Testinhalt verwenden.
Sitzungsabbruch	Vorgang und Dauer vor dem Abbruch dokumentieren; anschließend prüfen, ob SSH noch aktiv ist und das lokale Netzwerk gewechselt hat.	Genauer Zeitpunkt, aktive Anwendung, Netzwerkänderung, Ergebnis des Wiederaufbaus und relevante Logs.	Build-Jobs nicht wiederholt neu starten, damit der Ressourcenstatus zum Fehlerzeitpunkt erhalten bleibt.

Xcode-Buildfehler

Beim ersten aussagekräftigen Fehler beginnen, nicht bei der letzten Zeile

Signatur-, Cache-, Speicher- und Exportfehler treten oft verkettet auf. Toolchain und Reproduktionsbefehl festlegen und ab der frühesten eindeutigen Fehlerursache im Log prüfen.

SIGN

Zertifikate und Provisioning-Profile

Bundle Identifier, Team, Zertifikatstyp und Zweck des Provisioning-Profils müssen übereinstimmen. Automatische und manuelle Signierung nicht ohne dokumentierte Änderung im selben Target mischen.

Fehlgeschlagenes Target und Configuration dokumentieren
Gültigkeit und Geltungsbereich der Signatur-Assets prüfen
Vollständigen codesign-Fehlerkontext aufbewahren

KEYCHAIN

Keychain-Berechtigungen

Wenn der interaktive Build funktioniert, der CI-Build aber fehlschlägt, prüfen Sie, ob die Runner-Sitzung auf die benötigten Signatur-Assets zugreifen kann und welche Berechtigungsunterschiede bestehen.

Ausführenden Benutzer von lokalem Terminal und Runner vergleichen
Keychain-Status zur Laufzeit des Jobs bestätigen
Signaturpasswörter und vertrauliche Werte aus Logs entfernen

CACHE

DerivedData und Dependency-Cache

Zuerst prüfen, ob sich der Fehler zuverlässig reproduzieren lässt, dann nur das betroffene Projekt bereinigen. Nicht standardmäßig den gesamten Cache löschen.

Cache-Verzeichnisse und Trefferstrategie dokumentieren
Lockfile und Version des Abhängigkeitsmanagers festlegen
Vor und nach der Bereinigung je ein Build-Log aufbewahren

DISK

Festplattenspeicher

Archive, Simulatoren, Abhängigkeiten und frühere Artefakte belegen gemeinsam Speicher. Zu wenig Platz führt nicht nur zu Schreibfehlern, sondern kann auch beim Entpacken oder Signieren Probleme verursachen.

Freien Speicher der Systemplatte dokumentieren
Archiv- und Cache-Nutzung pro Projekt prüfen
Vor der Bereinigung festlegen, welche Artefakte erhalten bleiben müssen

EXPORT

Archivierung und Export

Fehlschlag bei der Archive-Erstellung und beim Export unterscheiden. Bei ersterem Kompilierung und Signierung, bei letzterem Exportoptionen, Zielkanal und Signaturdaten im Archiv prüfen.

Festhalten, ob das Archive erfolgreich erstellt wurde
Exportkonfiguration und Fehlerzusammenfassung aufbewahren
Übereinstimmung von Artefaktziel und Scheme bestätigen

REPRO

Minimal reproduzierbarer Befehl

Arbeitsverzeichnis, Xcode-Version, Scheme, Configuration und Befehl im Ticket angeben. Bei CI-only-Fehlern zusätzlich bereinigte Umgebungsunterschiede nennen.

Mindestens einen Kontextabschnitt vor und nach dem Fehler aufbewahren
Angeben, ob der Build über die grafische Oberfläche funktioniert
Bereits erfolglos getestete Schritte auflisten

CI-Runner-Fehlerbehebung

Labels bestimmen das Ziel, Verzeichnisse bestimmen die Rückstände nach einem Fehler

Wenn die Warteschlange stillsteht, zuerst Labels und Online-Status prüfen. Nach dem Start des Jobs Ausführungsbenutzer, Arbeitsverzeichnis, Parallelität und Bereinigung untersuchen.

Runner-Checkliste

Vier Variablen gemeinsam dokumentieren

Ausführbare Prüfung

LABEL Label-Zuordnung

Die geforderten Job-Labels müssen exakt den registrierten Runner-Labels entsprechen. Außerdem prüfen, ob Projekt- oder Branch-Bedingungen den Runner ausschließen.

WORKDIR Arbeitsverzeichnis

Das Verzeichnis muss für den dedizierten Ausführungsbenutzer les- und schreibbar sein. Projekte sollten keine temporären Pfade mit zurückbleibendem Zustand teilen.

CONCURRENCY Parallelitätslimit

Parallelität anhand von Arbeitsspeicher, Speicherplatz und Build-Typ festlegen. Bei zu vielen Jobs zuerst zwischen Warteschlange und Ressourcenwettbewerb unterscheiden.

CLEANUP Bereinigungsstrategie

Für jeden Job festlegen, was nach Abschluss erhalten oder gelöscht wird, und bei Fehlern genügend Logs und Diagnoseartefakte bewahren.

GitHub Actions

runs-on und Runner-Gruppe prüfen

Zugriffsbereich von Repository oder Organisation, Label-Schreibweise, Dienststatus und Rechte des Arbeitsverzeichnisses prüfen. Bei wartendem Job zuerst nach einem exakt passenden Online-Runner suchen.

GitLab CI

Tags und Projektberechtigungen prüfen

Job-Tags, Runner-Einschränkung, Projektberechtigungen und Parallelität prüfen. Nach Jobstart zusätzlich Executor-Logs und Projektskriptausgabe senden.

Andere self-hosted runner

Ausführungsidentität und Lebenszyklus festlegen

Runner-Software, Startmethode, Ausführungsbenutzer, Arbeitsverzeichnis und Bereinigungsskript angeben. Bei eigener Planung auch Jobannahme, Timeout und Exit-Code-Verarbeitung dokumentieren.

Kleines Begriffslexikon

Acht Begriffe für eine klare Problemabgrenzung

Wer bei Anfragen dieselben Begriffe verwendet, trennt physische Ressourcen, Remoteprotokolle und Automatisierungssoftware klar voneinander.

Physischer Knoten: Ein tatsächlich bereitgestelltes Apple-Silicon-Gerät, auf dem macOS läuft – keine virtuelle Instanz aus einem gemeinsam genutzten Host.
Dediziert: Rechenleistung, Arbeitsspeicher und lokaler Speicher der Bestellung werden von diesem Benutzer genutzt und nicht mit anderen Mandanten geteilt.
Keine virtuelle Maschine: Das System läuft direkt auf physischer Hardware. Bei der Fehleranalyse sind realer macOS-Host, Netzwerk und Peripherieverbindungen zu berücksichtigen.
VNC: Remote-Desktop-Protokoll für die grafische macOS-Oberfläche. Bildschirm-, Eingabe- und Zwischenablageprobleme werden meist auf Client- und Sitzungsebene geprüft.
SSH: Protokoll für Kommandozeilenverbindungen und automatisierte Ausführung. Es hilft festzustellen, ob der Knoten online ist und ob ein unabhängiges Problem der grafischen Sitzung vorliegt.
self-hosted runner: Von einem Team auf einem Cloud-Mac bereitgestelltes Programm, das CI-Plattformjobs entgegennimmt. Labels und Projektberechtigungen konfiguriert das Team selbst.
Build-Cache: Aufbewahrte Abhängigkeiten oder Zwischenartefakte zur Vermeidung wiederholter Downloads und Kompilierungen. Der Cache braucht Versionsschlüssel, Kapazitätsgrenzen und Bereinigungsregeln.
Parallelbetrieb: Anfrageoption für mehrere Geräte oder Thunderbolt-5-Verbindungen bei geeigneten Aufgaben. Das bedeutet nicht, dass alle Build-Tools automatisch linear schneller werden.

Richtlinien für Support-Tickets

Informationen liefern, mit denen der Support sofort diagnostizieren kann

Der Wert eines Tickets hängt nicht von seiner Länge ab, sondern von vollständigem Zeitpunkt, betroffenem Objekt, Reproduktionsweg und Originalfehler.

Ticket-Unterlagen DIAGNOSTIC PACK

Vor dem Senden prüfen

Bestellnummer und Knoten

Geben Sie die betroffene Bestellnummer und den tatsächlichen Knoten in Singapur, Tokio, Seoul oder Hongkong an. Mehrere Geräte getrennt kennzeichnen.

Reproduktionszeit

Geben Sie Zeitpunkt mit Zeitzone und Dauer an. Bei wiederkehrenden Problemen die letzten zwei bis drei Zeitpunkte aufführen.

Fehlerlogs

Kontext vor und nach dem Fehler, Befehl und Exit-Code aufbewahren. Screenshots können helfen, ersetzen aber keinen kopierbaren Logtext.

Ausgeführte Schritte

Geprüfte, geänderte und erneut getestete Punkte in Reihenfolge mit Ergebnis auflisten, damit der Support nichts wiederholen lassen muss.

Erwartetes und tatsächliches Ergebnis

Beschreiben Sie, was ursprünglich erreicht werden sollte und an welcher Phase der Vorgang aktuell stoppt. Bei Buildproblemen Scheme, Xcode-Version und Ausführungsart nennen.

Vor dem Senden Daten bereinigen

Alle Authentifizierungsdaten entfernen

Passwörter, private Schlüssel, Zugriffstoken, Signaturpasswörter, Zahlungsdaten und andere Login- oder Autorisierungsdaten aus Logs, Screenshots und Konfigurationsausschnitten entfernen.

Zwei Kontaktwege

Bestellprobleme per Ticket, allgemeine Fragen per E-Mail

Probleme zu bereits aufgegebenen Bestellungen bitte vorrangig im Portal als Ticket senden, damit Bestellung und Knoten zugeordnet werden können. Allgemeine Fragen können Sie per E-Mail an support@macvpsgo.com.

Portal-Ticket erstellen Kontaktmöglichkeiten anzeigen

Support-Eskalationsweg

Jedes Problem gehört in eine eigene Bearbeitungswarteschlange

Der richtige Einstieg ist effektiver als wiederholte Nachfragen. Hardware- und Verbindungsprobleme müssen der Bestellung zugeordnet werden; allgemeine Nutzungsfragen und Geschäftsanfragen beginnen am besten mit einer Beschreibung des Szenarios.

Beratung

Nutzungs- und Auswahlberatung

Für Fragen zu Xcode-Versionen, CI-Migration, Parallelität, Speicherbedarf und der Auswahl zwischen drei Konfigurationen.

Zur Kontaktseite

Verbindung

VNC- oder SSH-Problem

Nach dem Schnellcheck dieser Seite Bestellnummer, Knoten, Zeitpunkt und Ergebnisse der Gegenprüfung im Portal-Ticket angeben.

Ticket für Verbindungsproblem erstellen

Hardware

Vermutete Störung am physischen Knoten

Wenn VNC und SSH beide nicht erreichbar sind oder reproduzierbare Speicher-, Netzwerk- oder Geräteprobleme auftreten, keine weiteren Jobs starten und Zeitpunkt sowie Logs sichern.

Hardware-Ticket erstellen