Serverdiagnose

In die Core-Seitenleiste integriert, in der Reihenfolge Plugins → Serverdiagnose → Hash & Checksum. Sie benötigt weder eine SSH-Sitzung noch ein heruntergeladenes Plugin. Sämtlicher Laufzeitcode, Tests und Fixtures liegen in app/; das Modul hängt nicht von benachbarten Repositorys ab. Das Repository enthält keine doc.md, daher beschreiben dieses Dokument und beide READMEs die Implementierung.

Arbeitsablauf

Geben Sie einen Hostnamen, IPv4, IPv6 oder eine HTTP(S)/WS(S)-URL ein. Reine Hostnamen/IPs verwenden standardmäßig HTTPS; ausdrücklich angegebene URLs behalten bei der Anfrage Pfad, Abfrage und Port. Anmeldeinformationen in URLs, nicht unterstützte Schemata, Leer-/Steuerzeichen und Shell-artige Hostnamen werden abgelehnt. IPv6-Literale werden automatisch in eckige Klammern gesetzt; Zonenkennungen für scoped/link-local Adressen unterstützt der URL-Parser nicht.

Wählen Sie Auto (IPv4 bevorzugt, sonst IPv6), IPv4, IPv6 oder Beide. Durch Auflösen der Adressen können Sie eine bestimmte aktuelle Antwort wählen. Die Übersicht zeigt alle aufgelösten Antworten; Messungen testen die gewählte Adresse oder je eine Adresse pro angeforderter Familie. Beide Familien werden unabhängig gemessen. Das bloße Vorhandensein von AAAA bedeutet nie funktionierende IPv6-Konnektivität.

Diagnose starten führt DNS, Ping, Traceroute, HTTP, Komprimierung, TLS und die gewählten TCP-Ports aus. WebSocket muss ausdrücklich aktiviert werden. Jedes Werkzeug hat außerdem eine eigene Steuerung Starten/Stoppen. Es kann jeweils nur ein Diagnoselauf aktiv sein. Ein abgeschlossener Lauf bedeutet, dass die Werkzeuge beendet sind, nicht dass jede Messung erfolgreich war. Es gibt kein pauschales Urteil „Server offline“.

Zeitlimit, Paketanzahl, Wiederholungen, maximale Hops, DNS-Resolver, Protokollauswahl, warme Verbindung und der Vergleich HTTP/HTTPS sind einstellbar. Ein Wechsel des Ziels löscht eine zuvor gewählte IP-Adresse. Der Verlauf kann Berichte erneut öffnen, zwei Berichte vergleichen, löschen, JSON importieren, kopieren oder JSON/CSV/TXT über native Core-Dialoge exportieren. Helles/dunkles/System-Design gilt für den Diagnosebereich und wird in der bestehenden UI-Konfiguration gespeichert. CZ/DE/EN folgt sofort der Anwendungssprache.

Komponenten und Protokollverhalten

ICMP und Routen

Ping führt standardmäßig vier einzeln ausgeführte ICMP-Echo-Anfragen aus. Die Ergebnisse enthalten die gemessene RTT je Paket, Anzahl empfangen/gesendet, Verlust, Min/Durchschnitt/Max, Standardabweichung der Grundgesamtheit, mittlere absolute Differenz aufeinanderfolgender gemessener RTTs (Jitter), TTL/Hop Limit, sofern ausgegeben, und Zeitstempel. Eine Antwort <1 ms zählt als empfangen mit Obergrenze, statt eine numerische RTT zu erfinden. Unbekannte RTTs werden aus den Latenzstatistiken ausgeschlossen. Statistiken verwenden das aufbewahrte Fenster von höchstens 500 Paketen; die Anzahl gesendet/empfangen/verloren umfasst den ganzen Lauf. Diagramme zeigen die letzten 200 Beobachtungen mit unterschiedlichen Symbolen für Antworten, Antworten unterhalb der Auflösung, fehlende Antworten und ausdrückliche Zeitüberschreitungen von Anfrage/Prozess.

Eine fehlende Antwort kann auf ICMP-Filterung, Paketverlust oder Zeitüberschreitung zurückgehen; diese Beobachtungen identifizieren nicht eindeutig eine Firewall. Fehlende Programme, lokale Berechtigungsfehler und ungültige Werkzeugaufrufe sind eigene Werkzeugfehler, kein Paketverlust und keine Nichtverfügbarkeit des Servers. Es werden keine erhöhten Rechte angefordert.

Traceroute überträgt fortlaufend Hops, Adressen, einzelne Messungen, Mittelwerte und den beobachteten Anteil unbeantworteter Messungen. Reverse-DNS wird nach der Route mit dem gewählten Resolver aufgelöst. Wiederholungen vergleichen beobachtete Folgen von Hop-Adressen; Unterschiede können auf Lastverteilung zurückgehen. Unbeantwortete Zwischen-Hops belegen keine unterbrochene Route. Rohe Messmetadaten und die Methode erscheinen in aufklappbaren Details. macOS verlangt für Traceroute Wartezeiten in ganzen Sekunden; das tatsächlich gerundete Zeitlimit wird erfasst.

DNS

Die zwölf Eintragstypen sind A, AAAA, CNAME, MX, NS, TXT, SOA, SRV, CAA, PTR, DS und DNSKEY. Das Parsen des DNS-Formats prüft Transaktions-/Fragen-Identität, Eintragsgrößen, Schleifen von Komprimierungszeigern und Nachrichtengrenzen. Antworten bewahren die TTLs der Einträge, die Abfragedauer, den Resolver und die Zustände NXDOMAIN/NODATA/SERVFAIL/refused/timeout. Adressabfragen des Systems können keine TTL liefern; die separate Eintragsabfrage schon.

Das Verfolgen von CNAME ist auf acht Verweise mit Zykluserkennung begrenzt. Die Konsistenzprüfung wiederholt A/AAAA-Antworten des gewählten Resolvers und führt bei DNS-Tests für IP-Literale ein vorwärts bestätigtes PTR aus. Geänderte Antworten sind Beobachtungen, kein Beweis für einen DNS-Fehler. SRV-Abfragen verwenden den Zielnamen wie angegeben; geben Sie bei Bedarf einen Dienstnamen wie _service._tcp.example.org ein. DNSSEC ist immer nicht validiert. Vorhandene DS/DNSKEY-Einträge und selbst das AD-Flag eines Resolvers gelten nie als unabhängige Validierung.

HTTP, Leistung und Komprimierung

HTTP/1.1 akzeptiert diese Version nur dann als unterstützt, wenn sie tatsächlich zurückgegeben wurde. HTTPS-HTTP/2 erfordert ausgehandeltes h2; keine Ausweichlösung wird umetikettiert. Unverschlüsseltes HTTP/2 verwendet Prior Knowledge, keine HTTP/1.1-Upgrade-Messung. Die TLS-Prüfung bleibt für jede HTTP/WebSocket-Anfrage strikt.

Manuelle Weiterleitungen sind auf acht begrenzt; Schleifen, ungültige Ziele und zu viele Weiterleitungen schlagen ausdrücklich fehl. Die vollständige Kette erfasst Domainwechsel und Herabstufungen von HTTPS; Schema- und www-Wechsel sind in den Quell-/Ziel-URLs sichtbar. Anmeldeinformationen und Weiterleitungsschemata außer HTTP(S) werden abgelehnt. Jede Weiterleitung auf einen anderen Host wird unabhängig über den gewählten Resolver und die angeforderte IP-Familie aufgelöst.

Die Messungen umfassen DNS (falls ausgeführt), TCP, TLS, TTFB der endgültigen Antwort, gesamte TTFB einschließlich DNS/Weiterleitungen, Download, Weiterleitung und gesamte Laufzeit, tatsächliche Inhaltsbytes, Übertragungsgeschwindigkeit, Status, Antwort-Header, tatsächliche Serveradresse/Port, ALPN und geprüfte Wiederverwendung der Verbindung. DNS/TCP/TLS-Phasen, die auf einer festgelegten oder wiederverwendeten Verbindung nicht stattfanden, sind N/A, keine falschen Nullen. QUIC hat keine TCP-Phase; sein Handshake wird gesondert erfasst. Header-Übertragung oder gesamter Leitungs-Overhead werden nicht als Messung der Inhaltsbytes ausgegeben. Es handelt sich um Server-/Netzwerkzeiten, nicht um Seitendarstellung oder Lighthouse-Werte.

Jedes gewählte Protokoll verwendet dasselbe Ziel und dieselben Wiederholungen. IPv4/IPv6 und HTTP/HTTPS sind ausdrückliche Vergleichsoptionen. Das alternative Schema verwendet seinen Standardport. Jedes Protokoll startet pro Messung einen unabhängigen Prozess des mitgelieferten Clients. Eine Wiederverwendung der Verbindung wird nicht behauptet. Statistiken der Gesamtzeit umfassen Min/Durchschnitt/Median/Max/P95 nach Nearest-Rank sowie eine separate Fehlerrate für Transport/Protokoll; HTTP-Statuscodes bleiben sichtbar, auch wenn ein Server erfolgreich eine 4xx/5xx-Antwort liefert.

Die Komprimierungsprüfung sendet identity, gzip, deflate, br und (falls von der Laufzeitumgebung unterstützt) zstd als separate Accept-Encoding-Anfragen. Content-Encoding muss übereinstimmen, und die begrenzte Dekomprimierung muss gelingen. Ein Verhältnis wird nur berechnet, wenn Hash des dekodierten Inhalts, endgültige URL und Status mit der identity-Referenz übereinstimmen. Ignorierte Kodierungen gelten als nicht unterstützt; sich ändernde/dynamische Inhalte erhalten kein Verhältnis. Dies ist eine Beobachtung für diese URL/diesen Status, keine allgemeine Serverunterstützung.

Die Prüfung der Sicherheits-Header zeigt Vorhandensein und Wert von HSTS, CSP, X-Content-Type-Options, Referrer-Policy, Permissions-Policy und X-Frame-Options. Eine CSP-Direktive frame-ancestors kann letzteren ersetzen. Das Vorhandensein belegt nicht, dass die Richtlinie korrekt konfiguriert oder die Website sicher ist.

Anforderungen an HTTP/3 und Nachweis

HTTP/1.1, HTTP/2 und HTTP/3 verwenden denselben mitgelieferten curl-Client. macOS arm64 und Linux x64 verwenden curl 8.22.0, OpenSSL 3.5.9, nghttp2 1.70.0, ngtcp2 1.25.0 und nghttp3 1.18.0. Windows x64 verwendet den offiziellen statischen Build curl-for-win 8.22.0_3 von curl.se mit LibreSSL 4.3.3 und denselben HTTP-Bibliotheken. Es sind weder ein System-curl als Ausweichlösung noch ein Download zur Laufzeit oder Administratorrechte erforderlich. Das reproduzierbare Upstream-Build-Rezept für Windows ist https://github.com/curl/curl-for-win/tree/9d77e31e .

Bauen Sie vor dem Paketieren mit python3 scripts/native/build.py (Windows: python scripts/native/build.py). macOS/Linux benötigen C/C++-Werkzeuge, CMake, Ninja, Perl, make und pkg-config. Die Quellen sind in scripts/native/dependencies.lock.json über Version und Upstream-SHA-256 festgelegt. Das Skript prüft jeden Download, linkt Transportbibliotheken von Drittanbietern statisch und schlägt fehl, wenn HTTP2/HTTP3/SSL-Funktionen fehlen. Nur Bibliotheken des Betriebssystems bleiben dynamisch. Windows verwendet das festgelegte offizielle Binärarchiv, keinen lokal kompilierten Windows-Transportstack. Die mitgelieferte CA-Datei hat einen eigenen festgelegten Hash; Komponentenlizenzen und die Upstream-Build-Herkunft liegen der Laufzeitumgebung bei.

Client und Vertrauensspeicher werden außerhalb von app.asar in resources/native-runtime/<platform>-<arch>/ installiert. Jede Diagnose prüft vor der Verwendung Komponenten-Hashes, Architektur und Fähigkeiten der ausführbaren Datei. Konfigurationsdateien, Proxys, TLS-Vertrauensüberschreibungen aus der Umgebung und Variablen zur Bibliothekseinschleusung sind ausgeschlossen. curl läuft mit absolutem Pfad, ohne Shell, mit geprüftem CA-Vertrauen, einer ausdrücklich aufgelösten IP-Familie, ohne Cookies, ohne automatische Weiterleitungen und mit begrenzter Ausgabe und Zeit. Weiterleitungen werden von der Anwendung geprüft und neu aufgelöst. HTTPS auf anderen Ports als 443 wird unterstützt.

HTTP/3 verwendet --http3-only und gilt erst nach einer abgeschlossenen Übertragung, die HTTP-Version 3 meldet, und einer erfolgreichen Zertifikatsprüfung als bestätigt. HTTP-Fehlerantworten wie 404 können das Protokoll bestätigen. Alt-Svc ist eine Ankündigung, kein Nachweis. QUIC-Zeitüberschreitung, Zertifikatsfehler, DNS-Fehler, abgelehnte Verbindung, inkompatibles Protokoll und Komponentenfehler bleiben unterscheidbar. Eine UDP-Zeitüberschreitung lässt die Serverunterstützung unbestätigt. Die Dauer des QUIC-Handshakes wird nicht als TCP-Dauer ausgewiesen.

Jede Messung startet einen eigenen Prozess bzw. eine eigene Verbindung. Die Option „warm“ behauptet für den mitgelieferten Client keine Wiederverwendung der Verbindung. So bleiben Protokollvergleiche konsistent. Berichte enthalten Laufzeitversionen, Fähigkeiten, TLS-Prüfung und QUIC-Zeiten, während Verlauf und Export Antwortinhalte, URL-Abfragen und Authentifizierungs-Header entfernen.

Aktualisieren Sie diese Festlegungen und bauen Sie alle unterstützten Plattformen neu, wenn der Transportstack oder der CA-Vertrauensspeicher aktualisiert wird. Veröffentlichte Artefakte und Quell-Snapshots sind unveränderlich.

Core-IPC

Das Preload stellt nur window.chjCore.diagnostics bereit; alle Handler behalten die bestehende Prüfung des Absenders auf das Hauptfenster bei, und die Netzwerkarbeit bleibt im Hauptprozess. Ergebnisse verwenden { ok: true, value } oder { ok: false, error: { code, message } }.

Es wird keine allgemeine API für Shell, Dateisystem oder Netzwerk bereitgestellt. Kontextisolation, Sandbox, deaktivierte Node-Integration und die bestehende CSP des Renderers bleiben aktiv. Bestehende Plugin-Verträge sowie Prüfung/Ausnahmen des Updaters bleiben unverändert.

Grenzen und lokale Daten

• Ein Lauf, zwei aktive Werkzeuge, höchstens zwei Messungen von IP-Familien pro Werkzeug; TCP begrenzt jede Adresse zusätzlich auf vier Verbindungen.
• Zeitlimit pro Vorgang 250–30000 ms; 1–100 Pakete, 1–20 Wiederholungen, 1–40 Hops, 1–16 Ports. Normale Läufe stoppen nach fünf Minuten, Dauer-Ping nach dreißig Minuten. Der Traceroute-Unterprozess hat zusätzlich eine Grenze von 180 Sekunden.
• Prozessausgabe normalerweise 256 KiB; HTTP-Inhalt 2 MiB; dekomprimierter Inhalt 8 MiB; HTTP-Header begrenzt; keine Antwortinhalte gelangen in den Verlauf.
• Aufbewahrt werden höchstens 500 Pakete/Fortschrittsereignisse, fünf Läufe im Speicher, dreißig Verlaufsberichte und 10 MiB Verlauf. Der Verlauf verwendet den bestehenden privaten atomaren Schreiber unter <userData>/diagnostics/history.json (Modus 0600).
• Importe sind höchstens 2 MiB groß, Schema 1, mit begrenzter Verschachtelung und geprüften Ergebnissammlungen. CSV-Zellen werden maskiert und Formelpräfixe neutralisiert. URL-Abfragen/-Fragmente, Anmeldeinformationen, Cookies, Authentifizierungs-Header und rohe Inhalte sind aus gespeicherten/kopierten/exportierten Berichten ausgeschlossen. Rohe Details zeigen gemessene strukturierte Daten, keinen Paketmitschnitt und keinen aufbewahrten Antwortinhalt.
• Keine Cloud-Synchronisierung, keine automatische Anmeldung, keine Änderungen an der Serverkonfiguration und kein aggressives/unbegrenztes Scannen. Ziel/Ports/Resolver wählt der Benutzer ausdrücklich.

Plattformanforderungen und Prüfung

Es wurde keine neue npm-Abhängigkeit hinzugefügt. Die Implementierung verwendet integrierte Node-Module und das bestehende ssh2 der Anwendung. Sie installiert keine Systemwerkzeuge und fordert keine Administratorrechte an. Firewalls und UDP-Beschränkungen können verhindern, dass ein Test Unterstützung nachweist; aus einer Zeitüberschreitung allein lässt sich das nicht ableiten.

Die automatisierte Abdeckung liegt in diagnosticsCore.test.js, diagnosticsNetwork.test.js, diagnosticsHttp.test.js und diagnosticsIpc.test.js: Validierung/IPv6-Literale, native/lokale DNS-Fixtures für UDP+TCP, fehlende/doppelte Familienantworten und Resolver-Fehler, CNAME/Konsistenz, Fixtures für Systemargumente/Parsing, begrenzte echte Unterprozesse, Beobachtungen blockierten ICMPs, echtes lokales HTTP/1.1 und TLS h2, Weiterleitungen/Inhaltsgrenzen/Zeitlimits/Wiederverwendung, aktivierte/ignorierte Komprimierung, HTTP3-Fähigkeiten/Auswertung erfolgreicher Ergebnisse/Ablehnung von Ausweichlösungen, lokales CA-Vertrauen/Abweichung/Ablauf und echtes IPv6 HTTP/HTTPS, TCP-Verbindung/Ablehnung/simulierte Zeitüberschreitung, echte WebSocket- und SSH-Handshakes vor der Authentifizierung, Abbruch/Bereinigung/Teilergebnisse, Offline-Zustand, privater Verlauf (Hin- und Rückweg)/Ablehnung von Importen/Exporte, vertrauenswürdiges IPC und Preload-Abonnements.

npm test führt deterministische Tests ohne öffentliche Testserver aus. npm run test:diagnostics:ui führt scripts/smokeDiagnostics.js in einem grafischen Electron-Desktop aus, mit Produktions-UI/Preload/IPC und echten lokalen HTTP-/Komprimierungsmessungen. Nicht beteiligte Dienste sind nur in dieser Testumgebung durch Stubs ersetzt/offline. Geprüft werden Navigationsreihenfolge, Protokollergebnisse, Persistenz, CZ/DE/EN, beide Designs, Überlauf bei schmalem Fenster und Sandbox-Einstellungen. Setzt die Shell ELECTRON_RUN_AS_NODE, entfernen Sie die Variable für diesen Befehl.

Die aktuelle Laufzeitprüfung umfasst kontrollierte QUIC-Übertragungen, IPv4/IPv6, HTTPS auf einem Nicht-Standardport, 404-Antworten, TLS-Fehler und einen reinen TCP-Dienst, der Alt-Svc ankündigt. Ergebnisse je Build liegen jeder Veröffentlichung bei.

Ausdrückliche optionale Grenzen: keine unabhängige DNSSEC-Validierung (erfordert einen vollständigen Lebenszyklus mit validierendem Resolver/Vertrauensanker), kein Lighthouse-Audit (nur Server-/Netzwerkzeiten), kein Audit veralteter TLS-Versionen und kein Sperr-/CT-Dienst, keine Behauptung warmer Wiederverwendung bei HTTP3 und keine Messung warmer Wiederverwendung bei HTTP/3. Nicht unterstützte Fähigkeiten werden angezeigt, nicht simuliert.

Dateien dieser Änderung

Erstellt: die sieben Dienstdateien in src/main/diagnostics/; src/renderer/diagnostics.js, diagnosticsI18n.js, diagnostics.css; die vier Dateien test/diagnostics*.test.js; fünf Dateien unter test/fixtures/diagnostics/; scripts/smokeDiagnostics.js; dieses Dokument.

Integriert/aktualisiert: src/main/index.js, src/main/ipc/registerCoreIpc.js, src/preload/corePreload.js, src/renderer/index.html, app.js, i18n.js, package.json, app/README.md, das Stamm-README.md, .gitignore (vier Ausnahmen für öffentliche Fixtures) und die Stamm-Allowlist von gitleaks, die die bewusst öffentliche Fixture des TLS-Testschlüssels eng benennt. Der private Schlüssel der signierenden CA wurde verworfen; die Fixture wird von der Anwendung zur Laufzeit nie verwendet.