Diagnóstico do servidor

Integrado na barra lateral do núcleo, na ordem Plugins → Diagnóstico de servidor → Hash & Checksum. Não requer sessão SSH ou plug-in baixado. Todo o código de tempo de execução, testes e correções ao vivo no app/; o módulo não tem dependência de repositórios irmãos. O repositório não tem doc.md, então este documento e ambos os READMEs descrevem a implementação.

Fluxo de trabalho do usuário

Digite um nome de host, URL IPv4, IPv6 ou HTTP(S)/WS(S). Os nomes de host/IPs padrão para HTTPS; URLs explícitos mantêm seu caminho, consulta e porta durante a solicitação. Credenciais em URLs, esquemas não suportados, caracteres de espaço em branco/controle e nomes de host semelhantes a shell são rejeitados. Os literais IPv6 são entre colchetes automaticamente; os identificadores de zona local/de escopo/link não são suportados pelo analisador de URL.

Escolha Auto (preferir IPv4, caso contrário IPv6), IPv4, IPv6 ou ambos. Resolva endereços para escolher uma resposta atual específica. A visão geral exibe todas as respostas resolvidas; sondas testam o endereço selecionado ou um endereço por família solicitada. Ambas as famílias são medidas de forma independente. A presença AAAA sozinha nunca implica trabalhar a conectividade IPv6.

Executar diagnósticos executa DNS, ping, traceroute, HTTP, compressão, TLS e as portas selecionadas TCP. O WebSocket é opt-in. Cada ferramenta também tem um controle Run/Stop separado. Uma corrida de diagnóstico pode estar ativa de uma só vez. Uma execução completa significa que as ferramentas terminaram, não que todas as sondas tenham sido bem-sucedidas. Não há um veredicto geral de “servidor offline”.

Timeout, contagem de pacotes, repetições, salto máximo, resolvedor DNS, seleção de protocolo, conexão quente e comparação HTTP/HTTPS são configuráveis. Alterar o alvo limpa um IP selecionado anteriormente. O histórico pode reabrir, comparar dois relatórios, excluir, importar JSON, copiar ou exportar JSON/CSV/TXT através de diálogos Core nativos. O tema Light/dark/system aplica-se à seção de diagnóstico e é salvo na configuração da interface do usuário existente. CZ/DE/EN segue a linguagem de aplicação imediatamente.

Componentes e comportamento do protocolo

ICMP e rotas

Ping padrão para quatro solicitações de eco ICMP executadas individualmente. Os resultados contêm por pacote RTT medido, contagens recebidas/enviadas, perda, min/average/max, desvio padrão da população, diferença absoluta média entre RTTs medidos consecutivos (jitter), TTL/Hop Limit quando impressos e timestamps. Uma resposta <1 ms é contada como recebida com um limite superior, em vez de inventar um número RTT. As TRTs desconhecidas são excluídas das estatísticas de latência. As estatísticas usam a janela retida da maioria dos pacotes 500; as contagens sent/received/loss cobrem toda a execução. Os gráficos mostram as últimas observações do 200, com símbolos distintos para respostas, respostas de sub-resolução, respostas ausentes e prazos explícitos de solicitação/processo.

Uma resposta ausente pode refletir a filtragem ICMP, perda de pacotes ou tempo limite; essas observações não podem identificar um firewall conclusivamente. Os executáveis ausentes, as falhas de permissão local e as invocações de ferramentas inválidas são erros separados da ferramenta, não perda de pacotes ou indisponibilidade do servidor. Nenhuma escalada de privilégios é solicitada.

Fluxos de traceroute saltam, endereços, sondas individuais, meios e porcentagens não respondidas observadas. O DNS reverso é resolvido após a rota, usando o resolvedor selecionado. As repetições comparam as sequências de endereçamento de salto observadas; as diferenças podem refletir o equilíbrio da carga. O lúpulo intermediário não responde não estabelece uma rota quebrada. Os metadados e o método da sonda bruta aparecem em detalhes expansíveis. macOS requer esperas de traceroute de segundo inteiro; o tempo limite arredondado efetivo é gravado.

DNS

Os doze tipos de registro são A, AAAA, CNAME, MX, NS, TXT, SOA, SRV, CAA, PTR, DS e DNSKEY. A análise de fios DNS verifica a identidade da transação/questão, os tamanhos dos registros, os loops do ponteiro de compressão e os limites das mensagens. As respostas preservam os estados recordes de TTLs, temporização de consultas, resolvedor e NXDOMAIN/NODATA/SERVFAIL/refused/timeout. As pesquisas de endereço do sistema operacional não podem fornecer TTL; a consulta de registro separada pode.

CNAME seguinte é limitado a oito ligações com detecção de ciclo. A consistência repete as respostas A/AAAA do resolvedor selecionado e executa o PTR forward-confirmado para testes DNS IP-literal. Respostas alteradas são observações, não prova de uma falha do DNS. As consultas para SRV usam o nome de destino como indicado; insira um nome de serviço, como _service._tcp.example.org, quando necessário. DNSSEC é sempre not validado. A presença de DS/DNSKEY e até mesmo o sinalizador AD de um resolvedor nunca são tratados como validação independente.

HTTP, desempenho e compressão

HTTP/1.1 aceita essa versão como suportada apenas quando ela foi realmente retornada. HTTPS HTTP/2 requer h2 negociado; nenhum fallback é renomeado. O Cleartext HTTP/2 usa conhecimento prévio, não uma sonda de atualização do HTTP/1.1. A verificação do TLS permanece rigorosa para cada solicitação HTTP/WebSocket.

Os redirecionamentos manuais são limitados a oito; loops, destinos inválidos e redirecionamentos excessivos falham explicitamente. A cadeia completa registra alterações de vários domínios e downgrades HTTPS; esquemas e mudanças em www são visíveis nos URLs de origem/destino. Credenciais e esquemas de redirecionamento não-HTTP(S) são rejeitados. Cada redirecionamento entre hosts é resolvido independentemente através do resolvedor selecionado e da família de IP solicitada.

As medições incluem DNS (quando executada), TCP, TLS e TTFB de resposta final, em geral TTFB incluindo DNS / redireciona, download, redirecionamento e tempo total da parede, bytes reais da entidade, velocidade de transferência, status, cabeçalhos de resposta, endereço/porta real do servidor, ALPN e conexão verificada. As fases DNS/TCP/TLS não executadas em uma conexão fixa ou reutilizada são N/A, e não zeros falsos. QUIC não tem fase TCP; seu aperto de mão é gravado separadamente. A transferência de cabeçalho ou a sobrecarga total do fio não é afirmada como medição de bytes da entidade. São timings de servidor/rede, não renderização de página ou pontuações do Lighthouse.

Cada protocolo selecionado usa o mesmo alvo e repetições. IPv4/IPv6 e HTTP/HTTPS são opções de comparação explícitas. O esquema alternativo usa sua porta padrão. Cada protocolo inicia um processo de cliente empacotado independente por amostra. Reutilização de conexão não é afirmado. As estatísticas de tempo total incluem min/average/median/max/nearest-rank P95 e uma taxa de erro separada de transporte/protocolo; os códigos de status HTTP permanecem visíveis mesmo quando um servidor retorna com sucesso uma resposta 4xx/5xx.

Compressão envia identidade, gzip, deflate, br e (quando o tempo de execução suporta) zstd como separadamente Aceitar-codificação solicitações. A codificação de conteúdo deve corresponder e a descompressão limitada deve ter sucesso. Uma relação é calculada somente se o corpo decodificado hash, URL final e status corresponderem à linha de base da identidade. Codificações ignoradas não são suportadas; corpos dinâmicos / em mudança não têm relação. Esta é uma observação para esse URL/status, não para o suporte universal ao servidor.

Verificações de cabeçalho de segurança mostram presença e valor de HSTS, CSP, X-Content-Type-Options, Referenciador-Política, Permissões-Política e X-Frame-Opções. Uma diretiva CSP de frame-ancestors pode substituir a última. A presença não estabelece que a política está corretamente configurada ou que o site é seguro.

HTTP/3 requisitos e prova

HTTP/1.1, HTTP/2 e HTTP/3 usam o mesmo cliente de cacho empacotado. macOS arm64 e Linux x64 usar o cacho 8.22.0OpenSSL 3.5.9, nghttp2 1.70.0, ngtcp2 1.25.0 e nghttp3 1.18.0. Windows x64 usa a compilação estática oficial curl.se curl-for-win 8.22.0_3 com o LibreSSL 4.3.3 e as mesmas bibliotecas HTTP. Não é necessário nenhum fallback do sistema, download em tempo de execução ou permissão de administrador. A receita de compilação reprodutível a montante Windows é https://github.com/curl/curl-for-win/tree/9d77e31e .

Construa com python3 scripts/native/build.py (Windows: python scripts/native/build.py) antes da embalagem. macOS/Linux requer ferramentas C/C++, CMake, Ninja, Perl, make e pkg-config. As fontes são fixadas por versão e upstream SHA-256 em scripts/native/dependencies.lock.json. O script verifica cada download, vincula estaticamente bibliotecas de transporte de terceiros e falha sem os recursos do HTTP2/HTTP3/SSL. Apenas bibliotecas de sistemas operacionais permanecem dinâmicas. Windows usa o arquivo binário oficial fixado, não uma pilha de transporte Windows compilada localmente. O arquivo CA empacotado tem seu próprio hash fixado; o componente licença e a proveniência da compilação upstream acompanham o tempo de execução.

O cliente e a loja de confiança estão instalados fora do app.asar no resources/native-runtime/<platform>-<arch>/. Cada diagnóstico verifica o componente hash, a arquitetura e as capacidades executáveis antes de usar. Arquivos de config, proxies, TLS trust environment overrides e variáveis de injeção de biblioteca são excluídos. curl runs com um caminho absoluto, shell disabled, verificado CA trust, uma família IP resolvida explicitamente, sem cookies, sem redirecionamentos automáticos e saída e tempo limitados. Os redirecionamentos são validados e re-resolvidos pelo aplicativo. HTTPS em portas que não sejam 443 é suportado.

O HTTP/3 usa o --http3-only e é confirmado somente após uma transferência concluída informando a versão HTTP 3 da versão e a verificação bem-sucedida do certificado. Respostas de erro HTTP como 404 podem confirmar o protocolo. Alt-Svc é um anúncio, não uma prova. O tempo limite do QUIC, a falha do certificado, a falha de DNS, a recusa da conexão, o protocolo incompatível e a falha do componente permanecem distintos. Um timeout UDP deixa o suporte do servidor não verificado. O tempo de aperto de mão QUIC não é relatado como o tempo TCP.

Cada medição inicia um processo/conexão separado. A opção quente não reivindica a reutilização da conexão para o cliente empacotado. Isso mantém as comparações de protocolos consistentes. Os relatórios incluem versões em tempo de execução, recursos, verificação TLS e temporização QUIC, enquanto o histórico / exportação remove corpos, consultas de URL e cabeçalhos de autenticação.

Atualização estes pinos e reconstruir todas as plataformas suportadas ao atualizar a pilha de transporte ou loja de confiança CA. Artefatos publicados e instantâneos de origem são imutáveis.

Núcleo IPC

O pré-carregamento expõe apenas o window.chjCore.diagnostics; todos os manipuladores mantêm a verificação do remetente da janela principal existente e o trabalho de rede permanece na principal. Os resultados usam { ok: true, value } ou { ok: false, error: { code, message } }.

Nenhum shell genérico, sistema de arquivos ou rede API está exposto. O isolamento de contexto, o sandbox, a integração do nó desabilitado e o renderizador existente CSP permanecem ativados. Contratos de plug-in existentes e verificação/exceções do atualizador não são alterados.

Orçamentos e dados locais

• Uma execução, duas ferramentas ativas, no máximo duas sondas IP-família por ferramenta; TCP também limita cada endereço a quatro conexões.
• Tempo limite por operação 250–30000 ms; 1–100 pacotes, 1–20 repetições, 1–40 lúpulo, 1–16 portos. Corridas regulares param em cinco minutos; ping contínuo em trinta minutos. O subprocesso traceroute tem uma nova tampa 180-segundo.
• Saída do processo normalmente 256 KiB; corpo da entidade HTTP 2 MiB; corpo descompactado 8 MIB; cabeçalhos HTTP limitados; nenhum corpo de resposta entra no histórico.
• Mantenha na maioria dos pacotes 500/eventos de progresso, cinco execuções em memória, trinta relatórios de histórico e 10 MiB de histórico. A história usa o escritor atômico privado existente em <userData>/diagnostics/history.json (modo 0600).
• As importações são no máximo 2 MiB, esquema 1, com aninhamento limitado e coleções de resultados validados. Células CSV são escapadas e prefixos de fórmula neutralizados. As consultas/fragmentos de URL, credenciais, cookies, cabeçalhos de autenticação e corpos brutos são excluídos dos relatórios armazenados do /copied/exported. Os detalhes brutos mostram dados estruturados medidos, não um corpo de captura ou resposta retida de pacotes.
• Sem sincronização na nuvem, login automático, alterações de configuração do servidor ou varredura agressiva / ilimitada. O usuário escolhe explicitamente target/ports/resolver.

Requisitos de plataforma e verificação

Não foi adicionada nenhuma nova dependência de npm. A implementação usa o Node built-ins e o ssh2 existente do aplicativo. Ele não instala ferramentas de sistema nem solicita direitos administrativos. Firewalls e restrições UDP podem impedir que um teste estabeleça suporte; eles não podem ser inferidos a partir de um tempo limite sozinho.

A cobertura automatizada está em diagnosticsCore.test.js, diagnosticsNetwork.test.js, diagnosticsHttp.test.js e diagnosticsIpc.test.js: validação/IPv6 literais, nativos/locais DNS UDP+TCP fixs, respostas ausentes/dupla família e erros de resolução, CNAME/consistência, argumento OS/parsing fixings, processos filhos reais limitados, bloqueado ICMP observações, local real HTTP/1.1 e TLS h2, redirecionamentos/limites corporais/timeouts/reuse, compressão habilitada/ignorada, HTTP3 capacidades/sucesso-resultado análise/rejeição de retorno, confiança local CA/mismatch/expiration e real IPv6 HTTP/HTTPS, TCP conectar/refused/mock timeout, real WebSocket e SSH apertos de mão pré-autenticação, cancelamento/cleanup/partial resultados, estado offline, histórico privado de ida e volta/rejeição de importação/exportações, IPC confiável e assinaturas pré-carregadas.

npm test executa testes determinísticos sem servidores de teste públicos. O npm run test:diagnostics:ui executa o scripts/smokeDiagnostics.js em um desktop gráfico do Electron, usando UI/preload/IPC de produção e sondas HTTP/compressão locais reais. Os serviços não relacionados são excluídos/offline apenas neste arnês de teste. Ele verifica a ordem de navegação, os resultados do protocolo, persistência, CZ/DE/EN, ambos os temas, overflow de janela estreita e preferências sandbox. Se o shell definir ELECTRON_RUN_AS_NODE, desmarque-o para este comando.

A verificação do tempo de execução atual abrange transferências QUIC controladas, IPv4 / IPv6, HTTPS em uma porta não padrão, respostas 404 , falhas TLS e um serviço somente TCP publicidade Alt-Svc. Os resultados per-build acompanham cada liberação.

Limites opcionais explícitos: nenhuma validação DNSSEC independente (requer um ciclo de vida completo de resolução/ancoragem de confiança), nenhuma auditoria do Lighthouse (somente tempo de servidor/rede), nenhuma auditoria TLS obsoleta ou serviço de revogação/CT, nenhuma reivindicação de reutilização morna HTTP3 e nenhuma medição de reutilização quente HTTP/3. Recursos não suportados são exibidos em vez de simulados.

Arquivos nesta mudança

Criada: os sete arquivos de serviço em src/main/diagnostics/; src/renderer/diagnostics.js, diagnosticsI18n.js, diagnostics.css; os quatro test/diagnostics*.test.js arquivos; cinco arquivos sob test/fixtures/diagnostics/; scripts/smokeDiagnostics.js; este documento.

Integrado/atualizado: 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, raiz README.md, .gitignore (quatro exceções de fixação pública), e os gitleaks root permitlist nomeando por pouco o público deliberadamente TLS Fixture chave de teste. A chave privada CA de assinatura foi descartada; o dispositivo elétrico nunca é usado pelo tempo de execução do aplicativo.