Um teste HTTP da Dinamarca envia uma requisição GET real para sua URL e registra o código de status, tempo de resposta e se a resposta foi concluída com sucesso. Ele exercita a resolução DNS, handshake TCP, negociação TLS e o tempo até o primeiro byte do servidor — os mesmos passos que o navegador de um usuário dinamarquês percorre. Para um servidor hospedado em Copenhagen ou com peering local, os tempos de resposta devem ser rápidos. Para um servidor em Frankfurt, espere que apenas o handshake TCP leve 30–40 ms antes do início da transferência de conteúdo.

A Dinamarca é um país da UE com aplicação padrão do GDPR. Serviços voltados a usuários dinamarqueses frequentemente preferem infraestrutura hospedada na UE, e algumas configurações de CDN são definidas para atender usuários dinamarqueses a partir de um nó edge em Copenhagen ou Estocolmo. Um teste HTTP do nosso probe em Copenhagen confirma se o seu CDN está realmente atingindo um PoP local ou buscando de uma origem mais distante. Um TTFB rápido sugere cache local; um mais lento, consistente com a latência de Frankfurt ou Amsterdam, sugere que o edge está mais longe do que o planejado.

Se o teste HTTP retornar um status não-200 da Dinamarca mas tiver sucesso de outras regiões, as causas comuns incluem regras de geo-bloqueio, restrições de CDN no nível de país, ou regras de WAF que sinalizam requisições de faixas de IP dinamarquesas. O IP de origem Glesys AS42708 não deveria estar em nenhuma lista de bloqueio padrão, mas regras personalizadas definidas pelo operador do servidor ainda podem bloqueá-lo. Compare com testes da Suécia e da Alemanha para determinar se o problema é específico da Dinamarca.

Copenhagen é o principal hub de internet da Dinamarca e funciona como uma encruzilhada de roteamento entre a Escandinávia, a região do Báltico e a Europa Central. A Netnod opera um IX em Copenhagen junto com sua infraestrutura de Estocolmo, e o Danish Internet Exchange (DIX) oferece uma alternativa de peering gerida pela comunidade. Juntos, esses fazem de Copenhagen uma localização bem conectada para redes que precisam fazer peering com ISPs nórdicos e bálticos sem rotear por Frankfurt ou Amsterdam primeiro.

A Dinamarca conecta a península escandinava ao continente europeu por sua ligação terrestre via Jutlândia até a Alemanha. Essa geografia significa que Copenhagen tem caminhos de baixa latência tanto para Estocolmo (em torno de 20 ms) quanto para Hamburgo (em torno de 17 ms), dando alcance natural em ambas as direções. Links trans-Øresund para Malmö mantêm a latência para o sul da Suécia bem abaixo de 10 ms. Vários cabos submarinos conectam a Dinamarca ao Reino Unido, Noruega e aos estados bálticos, fornecendo diversidade de caminhos para o tráfego internacional.

Nosso nó de probe em Copenhagen roda no AS42708, operado pela Glesys AB. A Glesys é um provedor sueco-nórdico de hospedagem e infraestrutura com presença em data centers em Estocolmo, Gotemburgo e Copenhagen. A localização da Glesys em Copenhagen, em seu datacenter no município de Glostrup, dá ao nó de probe boa conectividade upstream para o ecossistema de hospedagem nórdico mais amplo. O AS42708 anuncia rotas via Netnod e tem acordos de trânsito que cobrem destinos nórdicos e da Europa Central.

O mercado de hospedagem dinamarquês inclui operadores locais e provedores internacionais. A TDC (AS3292) é a operadora nacional incumbente e opera uma parcela significativa do backbone dinamarquês. A Telia (AS1299) e a Telenor (AS2119) fornecem capacidade de trânsito adicional. Tráfego de alta largura de banda — streaming de vídeo, cargas de trabalho de nuvem — frequentemente roteia via Equinix Copenhagen, onde CDNs e provedores de nuvem mantêm nós de cache ou edge locais para atender usuários dinamarqueses sem buscar conteúdo de data centers mais distantes.

Para operadores voltados a usuários dinamarqueses, Copenhagen é o local de teste natural. Um servidor hospedado em Copenhagen ou com peering no DIX ou Netnod CPH deve alcançar a maioria dos usuários residenciais dinamarqueses em bem menos de 15 ms. Um servidor em Frankfurt adiciona 35–45 ms para usuários dinamarqueses antes de considerar qualquer variação de last-mile. A colocação de edge CDN em Copenhagen ou em Malmö próxima faz uma diferença material para aplicações sensíveis à latência que atendem o mercado dinamarquês.