Verbindung & Anmeldung
Sobald Sie Ihre Zugangsdaten haben, prüfen Sie Adresse, Port und Benutzernamen sowie Ihr lokales Netzwerk und den Client.
Keine Verbindung, Zahlung noch nicht bestätigt oder Anpassungen an der Entwicklungsumgebung nötig? Suchen Sie nach einem Symptom und gehen Sie die Prüfschritte der Reihe nach durch. Bei Fragen zu einer Bestellung oder Instanz melden Sie sich im Portal an und erstellen Sie ein Support-Ticket.
Sie haben bereits eine Bestellung? Prüfen Sie zuerst die Verbindungsdaten, Laufzeit und Zahlungsinformationen in den Instanzdetails.
Prüfen Sie zuerst, an welcher Stelle das Problem auftritt. Ein Verbindungsfehler bedeutet nicht automatisch, dass der Standort ausgefallen ist. Eine unbestätigte Zahlung heißt auch nicht, dass Sie erneut zahlen müssen.
Sobald Sie Ihre Zugangsdaten haben, prüfen Sie Adresse, Port und Benutzernamen sowie Ihr lokales Netzwerk und den Client.
Beginnen Sie mit dem Bestellstatus. Prüfen Sie Laufzeit, Zahlungsmethode und Transaktionsverlauf, statt sich allein auf Meldungen des Clients zu verlassen.
Trennen Sie Verbindungsprobleme von Problemen mit Ihren Tools. Wenn die Anmeldung funktioniert, aber der Build fehlschlägt, notieren Sie zuerst die Tool-Version und die vollständige Fehlermeldung.
Die Entfernung zur Stadt ist nur ein erster Anhaltspunkt. Auch Routing, Bildqualität und Dateigröße wirken sich auf die Remote-Nutzung aus.
Installieren Sie nicht sofort das System neu. Notieren Sie den genauen Wortlaut der Fehlermeldung und unterscheiden Sie zwischen Timeout, Verbindungsablehnung und Authentifizierungsfehler. So kann der Support die Ursache besser eingrenzen.
Bei einem Verbindungs-Timeout sollten Sie zuerst den Netzwerkpfad prüfen, statt das Passwort wiederholt einzugeben. Bei einer abgelehnten Verbindung prüfen Sie Port und Dienststatus. Bei einem Authentifizierungsfehler fahren Sie mit der Prüfung der Zugangsdaten fort.
Öffnen Sie die Instanzdetails im Portal und kopieren Sie die aktuelle Hostadresse und den SSH-Port. Entfernen Sie Leerzeichen, die beim Einfügen entstanden sind, und verwenden Sie keine Verbindungsdaten aus einer alten Bestellung oder von einem früheren Standort.
Vergewissern Sie sich, dass Ihr lokales Netzwerk Verbindungen über diesen Port zulässt. Unternehmensnetzwerke, Proxys oder Sicherheitssoftware können ausgehende Verbindungen einschränken. Testen Sie zum Vergleich ein anderes Netzwerk, das Sie verwenden dürfen.
Prüfen Sie den Instanzstatus im Portal sowie Ihre Firewall- und IP-Filterregeln. Öffnen Sie zur Fehlersuche nicht einfach alle Ports. Stellen Sie zuerst fest, ob Ihre aktuelle öffentliche IP-Adresse zugelassen ist.
Mit diesem Befehl sehen Sie in Ihrem Terminal ausführliche Verbindungsprotokolle. Ersetzen Sie vorher die Platzhalter in Großbuchstaben:
ssh -vv -p SSH_PORT USER@HOST
Schwärzen Sie vor dem Einreichen der Protokolle sensible Angaben wie Hostadresse, Benutzernamen und lokale Pfade. Laden Sie weder private Schlüssel noch Passwörter hoch.
Ein schwarzer Bildschirm in der grafischen Oberfläche ist ein anderes Problem als eine nicht erreichbare SSH-Verbindung. Testen Sie zuerst SSH, um festzustellen, ob die Maschine erreichbar ist. Funktioniert die Kommandozeile, liegt der Schwerpunkt auf der grafischen Sitzung und der Client-Konfiguration.
Verwenden Sie die Angaben aus den Instanzdetails und nicht den SSH-Port für die Bildschirmfreigabe. Prüfen Sie, ob Protokoll, Host und Authentifizierung im Client übereinstimmen.
Trennen Sie die Verbindung im Client und verbinden Sie sich erneut. Prüfen Sie, ob die Sitzung am Sperr- oder Anmeldebildschirm hängt. Ändern Sie die Anzeigeeinstellungen nicht gleichzeitig in mehreren Clients, sonst lässt sich das Problem schwerer nachvollziehen.
Verringern Sie zunächst Auflösung und Bildqualität und testen Sie erneut, nachdem große Uploads abgeschlossen sind. Tritt der schwarze Bildschirm nur in einem bestimmten Client auf, notieren Sie Version und Einstellungen und hängen Sie einen Screenshot an Ihr Support-Ticket an.
Ein Authentifizierungsfehler bedeutet meist, dass die Verbindung den Server erreicht hat. Prüfen Sie Benutzername und Authentifizierungsmethode, statt wiederholt den Standort zu wechseln.
Verwenden Sie den Anmeldenamen der aktuellen Instanz. Lesen Sie nach einer Neuinstallation oder einem Standortwechsel die Verbindungsdaten erneut aus. Wenn Sie Ihr Passwort geändert haben, verwenden Sie das neue Passwort.
Geben Sie den privaten Schlüssel an, der zum öffentlichen Schlüssel auf der Maschine gehört, und prüfen Sie die Dateiberechtigungen des privaten Schlüssels. Übergeben Sie SSH nicht die Datei mit dem öffentlichen Schlüssel und senden Sie Ihren privaten Schlüssel nicht an den Support.
Notieren Sie Zeitpunkt, Authentifizierungsmethode und Fehlermeldung. Hat sich nach einer Neuinstallation der Hostschlüssel geändert, bestätigen Sie zuerst die Identität der Instanz im Portal und aktualisieren Sie anschließend Ihren lokalen Eintrag.
Wir akzeptieren ausschließlich USDT-TRC20 sowie Visa / Mastercard / Amex über Stripe. Alle Beträge werden in US-Dollar abgerechnet. Welche Zahlungsoptionen verfügbar sind, sehen Sie im Portal.
Eine angezeigte Überweisung bedeutet nicht automatisch, dass die Bestellung bereits bestätigt ist. Prüfen Sie Netzwerk, Empfängeradresse und Betrag auf der Zahlungsseite und kontrollieren Sie den Status der Transaktion in der Blockchain. Die Bestätigung von USDT-TRC20 richtet sich nach dem Fortschritt im Netzwerk. Eine feste Dauer können wir nicht zusagen.
Rufen Sie im Portal den Zahlungsstatus der Bestellung auf. Überweisen Sie nicht an Zahlungsdaten, die bereits abgelaufen sind oder nicht zu Ihrer aktuellen Bestellung gehören. Ist die Transaktion bestätigt, die Bestellung aber noch nicht aktualisiert, senden Sie uns Bestellnummer, Transaktionshash, Betrag und Überweisungszeit mit Zeitzone. Übermitteln Sie niemals private Wallet-Schlüssel, Wiederherstellungsphrasen oder Passwörter. Überweisen Sie auch nicht erneut, während Sie auf die Bestätigung warten.
Prüfen Sie zunächst die Fehlermeldung auf der Zahlungsseite. Häufige Ursachen: Die Karte erlaubt keine Online- oder US-Dollar-Zahlungen, das verfügbare Limit reicht nicht aus, die Rechnungsdaten stimmen nicht überein oder eine Verifizierung durch die Bank steht noch aus. Fragen Sie bei Bedarf Ihre kartenausgebende Bank nach dem Ablehnungsgrund. Vermeiden Sie häufige Zahlungsversuche in kurzer Folge.
Wurde der Browser geschlossen, die Verifizierungsseite beendet oder eine ungewöhnliche Antwort angezeigt, prüfen Sie zuerst den Bestellstatus im Portal und entscheiden Sie danach, ob Sie es erneut versuchen. Geben Sie in einem Support-Ticket nur die Bestellnummer, den angezeigten Fehler und den Zeitpunkt an. Schwärzen Sie sensible Daten auf Screenshots. Ihre vollständige Kartennummer und der Sicherheitscode sind nicht erforderlich. Stripe verarbeitet die Kartenzahlungsdaten.
Prüfen Sie im Portal das Ablaufdatum Ihres aktuellen Abonnements, wählen Sie die Verlängerung und bestätigen Sie den angezeigten Preis. Kontrollieren Sie vor der Zahlung Modell, Laufzeit, Standort und Zusatzoptionen. Prüfen Sie danach, ob die neue Laufzeit angezeigt wird. Die Vorauszahlung ist für vier Laufzeitoptionen verfügbar: Tag, Woche, Monat und Quartal. Eine stundenweise Abrechnung gibt es nicht. Verlängerungsbetrag und Beginn der Laufzeit richten sich nach den Angaben in der Bestellbestätigung.
Alle Preise im Katalog sind in US-Dollar angegeben. XN Core M4 kostet pro Tag $21.4, pro Woche $57.7, pro Monat $106.8 und pro Quartal $290.5. XN Pro M4P kostet pro Tag $59.3, pro Woche $160.1, pro Monat $296.4 und pro Quartal $806.2. Prüfen Sie auf der Rechnung die Grundgebühr und alle ausgewählten Zusatzoptionen getrennt. Rechnungen und herunterladbare Belege finden Sie in den Abrechnungsdaten im Portal. Falls ein Download fehlschlägt, erstellen Sie ein Support-Ticket und geben Sie die Rechnungsnummer an.
Vor Ablauf erhalten Sie eine Erinnerung zur Verlängerung. Verlassen Sie sich trotzdem nicht allein darauf, sondern richten Sie sich eine eigene Kalendererinnerung ein. Klären Sie Zahlung und Laufzeit rechtzeitig und synchronisieren Sie wichtige Ergebnisse laufend mit Ihrem eigenen Speicher.
Ein eigener physischer Mac, keine virtuelle Maschine: Die grafische macOS-Oberfläche und die Kommandozeile stehen Ihnen zur Verfügung. Sichern Sie vor der Installation von Tools, einem Versionswechsel oder einer Neuinstallation Ihre Daten und prüfen Sie die Projektabhängigkeiten.
Beenden Sie laufende Builds, Übertragungen und Tests. Sichern Sie anschließend Ihren Code, Build-Ergebnisse, Konfigurationen und Zertifikatsdateien, die Sie behalten möchten. Bei einer Neuinstallation ändert sich die Systemumgebung; außerdem können lokale Daten gelöscht werden. Sie sollte daher nicht der erste Schritt bei Verbindungsproblemen sein.
Prüfen Sie im Portal die Neuinstallationsoptionen und Hinweise für Ihre Instanz. Wenn Sie Hilfe brauchen, erstellen Sie über die betreffende Bestellung ein Support-Ticket und nennen Sie die Instanz, die neu installiert werden soll, sowie Ihre abgeschlossene Datensicherung. Rufen Sie nach der Neuinstallation die Verbindungsdaten erneut ab und prüfen Sie macOS-Version, Tool-Pfade und Speicherplatz, bevor Sie Ihr Projekt wiederherstellen. Beurteilen Sie die neue Umgebung nicht anhand alter Verbindungsdaten.
Prüfen Sie zuerst, welche Xcode-, SDK- und macOS-Version Ihr Projekt benötigt. Kontrollieren Sie anschließend das ausgewählte Entwicklerverzeichnis. Wenn mehrere Xcode-Versionen installiert sind, muss die Version, die sich in der grafischen Oberfläche öffnet, nicht mit der für Builds über die Kommandozeile verwendeten Version übereinstimmen.
xcode-select -p
xcodebuild -version
uname -m
df -h
Die ersten drei Befehle zeigen Entwicklerverzeichnis, Xcode-Version und Architektur an. Mit dem letzten prüfen Sie den verfügbaren Speicherplatz. Auf Apple Silicon sollte als native Architektur arm64 ausgegeben werden. Bevor Sie wechseln, prüfen Sie, ob der Pfad zur gewünschten Anwendung existiert. Mit sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer wählen Sie das entsprechende Verzeichnis aus. Die Änderung wirkt sich auf nachfolgende Builds über die Kommandozeile aus.
Prüfen Sie vor der Verwendung von Homebrew mit command -v brew und brew --version, ob der Befehl aus der erwarteten Umgebung stammt. Installieren Sie Abhängigkeiten mit den im Projekt festgelegten Versionen und ändern Sie nicht gleichzeitig Toolchain, Abhängigkeiten und Build-Skripte. Bei einem Fehler helfen dem Support die Tool-Versionen, der ausgeführte Befehl und der letzte Teil der Fehlermeldung mehr als die Angabe „Kompilierung funktioniert nicht“.
Sichern Sie mindestens drei Arten von Dateien: noch nicht übermittelten Code und Projektkonfigurationen, Build-Ergebnisse und Testergebnisse sowie Abhängigkeitslisten und Lizenzdateien, die Sie zur Wiederherstellung Ihrer Umgebung benötigen. Zertifikate und Schlüssel sollten verschlüsselt gespeichert und nur entsprechend den Team-Berechtigungen weitergegeben werden. Legen Sie sie weder in öffentlichen Repositories ab noch hängen Sie sie an Support-Tickets an.
Mit scp oder rsync können Sie Dateien in Ihren eigenen Speicher übertragen. Testen Sie zunächst mit einer kleinen Dateiauswahl Pfad, Berechtigungen und Lesbarkeit, bevor Sie ganze Verzeichnisse kopieren. Vergleichen Sie anschließend Dateianzahl, Größe oder Prüfsummen und öffnen Sie wichtige Dateien testweise. Eine zusätzliche SSD ist externer Speicher, aber kein eigenständiges Backup. Sie synchronisiert Daten auch nicht automatisch zwischen Standorten.
Verlassen Sie sich nicht darauf, Daten nach Ablauf wiederherstellen zu können. Welche Daten aufbewahrt oder gelöscht werden, richtet sich nach den Hinweisen im Portal und den geltenden Bestimmungen. Wenn Sie besondere Anforderungen an eine Migration haben, erstellen Sie vor Ende der Laufzeit ein Support-Ticket und schließen Sie Ihre Datensicherung ab.
An allen sechs Standorten sind zwei Modelle verfügbar. Berücksichtigen Sie bei der Auswahl Ihren Standort, die Übertragungsrichtung von Code und Build-Ergebnissen sowie die Frage, ob Sie überwiegend SSH oder eine grafische Oberfläche nutzen.
Grenzen Sie die Auswahl zunächst anhand der geografischen Lage ein und testen Sie anschließend Ihre eigene Netzwerkverbindung. Die Tabelle dient als Orientierung und ist keine Zusage zu gemessenen Latenzzeiten. Routing durch den Internetanbieter und die lokale Netzwerkverbindung beeinflussen das Ergebnis. SSH benötigt keine kontinuierliche Bildübertragung. Bei der Bildschirmfreigabe wirken sich Latenz und Bandbreite stärker aus.
| Standort | Geeignete Regionen | Bei der Verbindung zuerst prüfen |
|---|---|---|
| Singapur | Südostasien | Vergleichen Sie die Reaktionszeit bei der täglichen Nutzung und die Geschwindigkeit der Code-Synchronisierung. |
| Japan (Tokio) | Ostasien | Testen Sie zuerst mit geringer Bildqualität und Ihrem gewohnten Client für die Bildschirmfreigabe. |
| Südkorea (Seoul) | Nordostasien | Vergleichen Sie das Routing Ihres lokalen Internetzugangs, statt sich nur an der Entfernung auf der Karte zu orientieren. |
| Hongkong | Südchina und Südostasien | Prüfen Sie Einschränkungen Ihres lokalen Netzwerks und die Reaktionszeit beim Upload großer Dateien. |
| US-Ostküste | Ostküste Nordamerikas und Westeuropa | Beobachten Sie sowohl den Rücktransfer von Build-Ergebnissen als auch die Reaktionszeit der interaktiven Verbindung. |
| US-Westküste | Westküste Nordamerikas | Prüfen Sie, wo sich Ihr Team, der Codespeicher und die Empfänger der Build-Ergebnisse befinden. |
Wenn die Bedienung stockt, pausieren Sie zuerst große Dateiübertragungen, verringern Sie die Auflösung der Bildschirmfreigabe und vergleichen Sie das Ergebnis. Bleibt das Problem bestehen, notieren Sie Netzwerktyp, Standort, Client-Version und Zeitpunkt. Beurteilen Sie nicht anhand eines einzelnen Tests, ob ein ganzer Standort nicht verfügbar ist.
Sichern Sie zuerst die Daten auf der aktuellen Instanz und notieren Sie Tool-Versionen, Umgebungsvariablen, Aufgabenkonfiguration und Netzwerkregeln. Prüfen Sie anschließend im Portal die Bestelloptionen für den Zielstandort. Wenn dafür Ihr aktuelles Abonnement angepasst werden muss, klären Sie Kosten und Ablauf zuerst über ein Support-Ticket. Gehen Sie nicht davon aus, dass Ihre Festplatte beim Standortwechsel automatisch übertragen wird.
Sobald Sie die Zielinstanz erreichen, stellen Sie die Dateien wieder her und testen Sie Build, Signierung, Upload von Ergebnissen und geplante Aufgaben. Aktualisieren Sie die im Team verwendete Hostadresse und die Regeln für zugelassene IP-Adressen. Beenden Sie die ursprüngliche Instanz erst, wenn die neue einwandfrei läuft. Vermeiden Sie während der Migration parallele Veröffentlichungsaufgaben, die doppelte Ergebnisse erzeugen können.
In Singapur, Japan (Tokio), Südkorea (Seoul), Hongkong, an der US-Ostküste und an der US-Westküste sind XN Core M4 (M4 / 16GB / 256GB SSD) und XN Pro M4P (M4 Pro / 64GB / 2TB SSD) verfügbar. Die aufgeführten Konfigurationen sind gut verfügbar. Den aktuellen Status sehen Sie im Portal.
Für reguläre App-Builds und CI eignet sich zunächst der XN Core M4. Für umfangreiche parallele Builds und Aufgaben mit hohem Bedarf an gemeinsamem Arbeitsspeicher kommt der XN Pro M4P infrage. Zusätzlich sind externe SSDs mit +1TB oder +2TB verfügbar. Sie ändern nicht die interne SSD des Modells. Die Standorte sind an 365 Tagen im Jahr regulär in Betrieb. Bei Verbindungsproblemen sollten Sie Netzwerk, Authentifizierung und System der Reihe nach prüfen.
Melden Sie sich im Portal an, wählen Sie im Support-Bereich die betreffende Bestellung aus und beschreiben Sie das Problem. Bestellinformationen gehören ins Ticket. Senden Sie bei öffentlichen Anfragen keine Passwörter oder vollständigen Zahlungsdaten.
Nennen Sie Bestellnummer, Standort und Modell. Wenn Sie mehrere Instanzen haben, geben Sie an, um welche es geht. So vermeiden wir, dass Protokolle einer anderen Maschine herangezogen werden.
Geben Sie an, wann das Problem zum ersten Mal auftrat und welche Zeitzone gilt. Schreiben Sie dazu, ob es dauerhaft oder nur gelegentlich auftritt, was zuletzt normal funktioniert hat und welche Einstellungen Sie davor geändert haben.
Listen Sie die Schritte, Client- oder Tool-Versionen, die genaue Fehlermeldung und bereits durchgeführte Prüfungen auf. Nennen Sie bei Bedarf auch die Ergebnisse von Tests mit einem anderen Netzwerk oder Client.
Fügen Sie bei Bedarf Screenshots oder relevante Protokollauszüge hinzu. Entfernen Sie Passwörter, private Schlüssel, sensible Zertifikatsdaten und Zahlungsdaten. Fehlercodes, die für das Problem wichtig sind, sollten sichtbar bleiben.
Standort und Modell → Bestellnummer → Zeitpunkt und Zeitzone → erwartetes Ergebnis → tatsächliche Fehlermeldung → bereits durchgeführte Prüfungen. Wenn Builds oder Veröffentlichungen betroffen sind, nennen Sie die betroffenen Aufgaben. „Dringend“ allein hilft bei der Einschätzung nicht weiter.
Ergänzen Sie neue Ergebnisse im selben Ticket, damit der gesamte Kontext erhalten bleibt. Angaben zu Antwortzeiten, Bearbeitungsstand und voraussichtlicher Rückmeldung finden Sie im Portal und in den Ticket-Antworten. Wir sagen keine festen Antwortzeiten zu, die nicht bestätigt wurden. Betriebszeit der Standorte und Bearbeitungszeit des Supports sind nicht dasselbe.
Sie haben noch nicht bestellt? Schreiben Sie uns, wofür Sie den Mac nutzen möchten, wie lange Sie ihn voraussichtlich benötigen und in welcher Region Sie sich befinden. Wir beraten Sie zu Modell und Standort. Bei einer bestehenden Bestellung erstellen Sie am besten im Portal ein Support-Ticket, damit wir das Problem der richtigen Instanz zuordnen können.
Fragen vor dem Kauf, Anfragen von Teams und sonstige Anliegen richten Sie bitte an support@xcodenet.com. Senden Sie per E-Mail keine Passwörter, privaten Schlüssel oder vollständigen Kartendaten.