> A revisão linguística desta tradução está em curso. Em caso de dúvida, consulte o [original em inglês](https://www.sm.ch-j.eu/docs/i18n/en/server-diagnostics.md). # 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 | Componente | Implementação e interpretação | | --- | --- | | `common.js` | Valida alvos/opções, limites e valores de enum; conversão IDNA; estatísticas numéricas excluem valores desconhecidos. | | `dnsDiagnostics.js` A resolução de endereço do sistema | usa o `dns.lookup` para honrar a configuração do SO e hospedar arquivos. As consultas de registro usam UDP DNS limitado com o fallback TCP para respostas truncadas contra `dns.getServers()` ou o resolvedor personalizado/público explicitamente escolhido. Nenhum interruptor implícito para público DNS. | | `processTools.js` O | Executa o ping/traceroute do sistema operacional com um array de argumentos e `shell: false`, saída limitada, tempo limite explícito e limpeza abortar/matar. Paralisa as respostas de pacotes e saltos, em vez de tratar a duração do processo como RTT. | | `httpDiagnostics.js` | Ondulação empacotada para HTTP/1.1, HTTP/2 e HTTP/3; verificação rigorosa do certificado e família IP fixada. Cada versão é solicitada de forma independente; a versão real é gravada. | | `socketDiagnostics.js` O | Explicit TLS version probes, TCP connects/passive banners, pré-autenticação SSH host-key observation usando a dependência ssh2 existente e validação de atualização opcional RFC 6455. | | `diagnosticsService.js` | Executa e cancela ferramentas, seleciona/valida endereços, transmite progresso, preserva medições parciais e possui o prazo de execução. | | `historyStore.js` | Histórico local limitado, redação, importações verificadas por esquema e exportações de dados medidos. | ### 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/-/`. 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 } }`. | Canal / método de pré-carga | Payload / resultado | | --- | --- | | `diagnostics:resolve` / `resolve(options)` | Destino/configurações validados → destino e endereços resolvidos. No máximo dois pedidos de resolução simultâneos. | | `diagnostics:start` / `start(options)` | Alvo validado/settings/tool seleção → ID de trabalho opaco e relatório inicial. | | `diagnostics:cancel` / `cancel(id, tool?)` | Cancelar uma ferramenta ativa/fileirada ou toda a execução. | | `diagnostics:get` / `get(id)` | Instantâneo de uma execução conhecida ou relatório salvo. | | `diagnostics:history` / `history()` | Resumos de história local. | | `diagnostics:removeHistory` / `removeHistory(id)` | Remova o item de histórico selecionado. | | `diagnostics:copy` / `copy(id, format)` O | Main escreve um relatório conhecido para a área de transferência. | | `diagnostics:export` / `export(id, format)` O | A JSON/CSV/TXT através da caixa de diálogo de gravação nativa; o renderizador não pode fornecer um caminho do sistema de arquivos. | | `diagnostics:import` / `import()` | Seletor de arquivos nativo, tamanho/schema/depth validação e redação antes de armazenar. | | `diagnostics:progress` / `onProgress(callback)` | Resolvido endereços, inícios/conclusão de ferramentas, pacotes, saltos, amostras HTTP e conclusão; retorna um retorno de chamada de cancelamento. | 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 `/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 | Plataforma | ICMP | Rota | Outros protocolos | | --- | --- | --- | --- | | Windows 10/11 | `ping.exe -4/-6` | `tracert.exe -4/-6`, ICMP | Empacotado curl.exe com HTTP/2 e HTTP/3. Os campos RTT localizados não dependem da palavra “tempo”. | | macOS | `/sbin/ping`, `/sbin/ping6` | `/usr/sbin/traceroute`, `/usr/sbin/traceroute6`, UDP; esperas de segundo inteiro | Enrolado com HTTP/2 e HTTP/3. | | Ubuntu/Linux | iputils `ping -4/-6` | padrão `traceroute -4/-6`, UDP | Enrolado com HTTP/2 e HTTP/3; em falta ICMPAs ferramentas /route são relatadas separadamente. | 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.