Ping

Ping er et gratis værktøj, der kontrollerer, om et website, en server eller en port kan nås, og viser svartid, statuskode eller fejl.

Hvad tester et ping-tjek egentlig?

Et ping-tjek undersøger, om et eksternt system svarer fra det netværk, hvor kontrollen køres. Den præcise test afhænger af den valgte protokol.

• HTTP(s) kontrollerer en webadresse via HTTP eller HTTPS. Det er velegnet til websites, API'er og webtjenester, fordi kontrollen kan returnere en HTTP-statuskode.
• Ping (ICMP) kontrollerer, om en vært svarer på ekkoforespørgsler via Internet Control Message Protocol. Det er den traditionelle netværksbetydning af "ping".
• Host / Port kontrollerer, om en bestemt netværksport kan nås på en vært. Det kan for eksempel være en SMTP-mailserver, en POP-server eller et databaseslutpunkt.

De tre kontroller besvarer lidt forskellige spørgsmål. Et ICMP-svar viser, at en vært accepterer og besvarer denne type netværkstrafik, men beviser ikke, at dens website eller mailtjeneste fungerer. Et HTTP-svar indeholder en statuskode, som kan pege på en fejl. En vellykket portkontrol viser, at porten kan nås, ikke at et login eller en databaseforespørgsel på applikationsniveau vil lykkes.

Hvordan bruger jeg Ping?

Vælg den relevante Ping-protokol, indtast den tilhørende adresse, og start kontrollen. Brug den type input, som protokollen forventer.

1. Vælg HTTP(s), og indtast en komplet URL, for eksempel https://www.example.com/status, når du fejlsøger et website, et API-slutpunkt eller en webtjeneste.
2. Vælg Ping (ICMP), og indtast en vært, for eksempel server.example.com eller en IP-adresse, når du vil kontrollere, om en server svarer på ICMP-trafik.
3. Vælg Host / Port, indtast værten, og angiv derefter den numeriske port. En SMTP-tjeneste til indsendelse af mail bruger for eksempel ofte port 587, mens HTTPS ofte bruger port 443.

Føj ikke en URL-sti til en kontrol, der kun forventer et værtsnavn. Omvendt kan en HTTP-kontrol kræve hele stien, hvis problemet rammer en bestemt API-rute eller side og ikke hele domænet. Transportporte bruger 16-bitværdier fra 0 til 65.535. Port 0 er reserveret og bruges normalt ikke som tjenesteport. Mellemrum, kommaer og betegnelser som "port 443" er ikke en del af et portnummer.

Ping-kontrollen køres på serveren. Dine input til Ping sendes til serveren via HTTPS og gemmes ikke. Undgå at indsætte adgangskoder, API-nøgler eller andre hemmelige oplysninger i en URL, da URL'er kan gøre dem synlige for den eksterne tjeneste og gennem andre dele af den normale webinfrastruktur.

Hvordan læser jeg ping-resultatet?

Se først på resultatet for tilgængelighed. Brug derefter svartiden, HTTP-statussen eller fejlresultatet til at afgrænse problemet.

Et tænkt HTTP-resultat kan for eksempel vise Online, en svartid på 180 ms og statuskode 200. Statuskode 200 betyder, at anmodningen lykkedes. Et 404-svar betyder, at oprindelsesserveren ikke fandt en aktuel repræsentation af den ønskede ressource eller ikke vil oplyse, at den findes. Et 5xx-svar (Server Error) tilhører klassen Server Error. Den præcise årsag afhænger af den konkrete statuskode.

Et resultat med Offline betyder ikke altid, at hele maskinen er offline. En firewall kan blokere ICMP, selv om HTTPS stadig fungerer, eller én port kan være lukket, mens andre tjenester fortsat er tilgængelige. Kør den kontrol, der svarer til den tjeneste, brugerne forsøger at nå.

Typiske fejl, som ping kan afsløre

Hvis et website ikke indlæses, skal du begynde med HTTP(s) og den præcise URL, der er berørt. Hvis domænet svarer, men én side returnerer 404, bør du kontrollere ruten, omskrivningsreglerne eller udrulningen. Hvis HTTPS udløser en certifikatadvarsel i browseren, skal du bruge SSL-opslag til at se certifikatoplysningerne i stedet for kun at stole på ping. HTTP headers opslag kan også vise omdirigeringer og svarheadere.

Hvis en mail ikke kommer frem, skal du bruge Host / Port med mailserverens værtsnavn og den port, der er konfigureret i programmet til afsendelse eller modtagelse. At en SMTP-port kan nås, beviser ikke, at serveren accepterer en bestemt meddelelse. Godkendelsesfejl, spamfiltrering, DNS-poster til mail og modtagerens politikker ligger uden for en grundlæggende portkontrol.

Når du har flyttet et website til en ny udbyder, skal du kontrollere værtsnavnet med ICMP eller HTTP, alt efter hvad der er relevant. Kontrollér DNS-posten, og tag højde for cachelagrede svar. Whois-opslag kan hjælpe med at bekræfte oplysninger om domæneregistreringen, men viser ikke, hvilket DNS-svar hver enkelt resolver har på det aktuelle tidspunkt.

Hvorfor kan DNS-cache få et korrekt resultat til at se forkert ud?

DNS-cache kan medføre, at værktøjets server og din egen enhed i en periode oversætter det samme værtsnavn til forskellige adresser. Rekursive resolvere gemmer DNS-svar i henhold til deres levetid, ofte kaldet TTL, og nogle programmer og operativsystemer har også lokale cacher.

"Udbredelse" bruges ofte som betegnelse for denne forsinkelse, selv om DNS-poster ikke spredes overalt gennem én koordineret proces. Hver cache udløber efter sin egen tidsplan. En nyligt ændret post kan derfor fungere på én forbindelse, mens en anden stadig bruger den tidligere adresse.

Da værktøjet kører kontrollen på sin egen server, afspejler resultatet serverens netværksrute og DNS-visning på det pågældende tidspunkt. Det kan ikke bevise, at alle danske bredbåndsudbydere, mobilnetværk eller virksomhedsresolere ser den samme destination. Sammenlign resultatet med en lokal kontrol, og slå de relevante DNS-poster op, når geografiske forskelle har betydning.

Ofte stillede spørgsmål

Hvad sker der med domænenavne, der indeholder accenter eller ikke-latinske tegn?

IDNA konverterer egnede Unicode-domæneetiketter til ASCII A-labels. Punycode er den kodningsalgoritme, der bruges i de relevante A-labels. Browsere konverterer ofte automatisk den læsbare stavemåde, men værtsfelter og diagnosesystemer kan kræve A-label-formatet. Kontrollér stavemåden nøje, da Unicode-tegn, der ligner hinanden, kan henvise til forskellige domæner.

Bliver en lav svartid ved med at være lav?

Nej. Svartiden varierer afhængigt af routing, belastningen på netværket og serveren samt den fysiske afstand. Registrer flere kontroller på sammenlignelige tidspunkter, og undersøg vedvarende ændringer i stedet for at betragte et enkelt langsomt svar som bevis på en fejl.

Før du ændrer indstillinger for DNS, firewall eller server, skal du kontrollere, at du har testet præcis det værtsnavn, den URL-sti og den port, som den berørte tjeneste bruger. Gem tidspunktet for resultatet, og sammenlign det med lokale logfiler, så oplysningerne fra begge sider af forbindelsen kan matches.