VPS em Nova York: o que realmente importa

O que um VPS em Nova York realmente oferece

Um VPS em Nova York está localizado num dos dois grandes mercados de interligação da costa leste dos Estados Unidos. O outro é Ashburn, na Virgínia. O que obtém é um tempo de ida e volta reduzido para utilizadores entre Boston e Washington, além do percurso de fibra mais curto entre a América do Norte e a Europa. Se os seus utilizadores estiverem distribuídos uniformemente pelo continente, uma localização central normalmente oferece um serviço melhor. Distinguir estes dois casos exige medições, não suposições.

Por que a hospedagem de VPS de Nova York é, na maioria dos casos, hospedagem de Nova Jersey

Manhattan concentra os principais hotéis de operadoras. O 60 Hudson Street é o mais conhecido: um edifício art déco em Tribeca, concluído em 1930, que abriga mais de 300 operadoras e provedores de cloud, além dos pontos de troca que atendem a região, incluindo DE-CIX New York e NYIIX. O 32 Avenue of the Americas desempenha a mesma função a algumas quadras, e o 165 Halsey Street, em Newark, é o equivalente do lado de Nova Jersey.

É nesses edifícios que as redes se interligam. Eles não abrigam grandes quantidades de capacidade computacional, porque a energia e o espaço físico em Manhattan são caros e difíceis de ampliar. Os grandes data centers ficam do outro lado do Hudson, em Secaucus, Weehawken, Carteret, Piscataway e Newark. Um provedor que vende uma VPS de "Nova York" quase sempre está a referir-se a um rack situado algures nesse anel, a cerca de 40 km de Midtown. A fibra adicional acrescenta bem menos de 1 milissegundo, por isso uma carga de trabalho web nunca notará a diferença. Pergunte em que edifício o servidor está apenas se precisar de um cross-connect com uma rede específica.

O que trouxe a capacidade para esta área metropolitana

Foram quatro fatores, e cada um reforça os outros.

• Os cabos transatlânticos chegam mesmo ao lado. Wall Township e Manasquan, na costa de New Jersey, formam o cluster mais movimentado do país. O Havfrue, comercializado como AEC-2, liga Wall a Blaabjerg, na Dinamarca, com ramificações para a Irlanda e a Noruega. O Seabras-1 parte da mesma estação para o Brasil, e o TGN Atlantic atravessa o Atlântico até à Europa. O Apollo chega a terra em Manasquan, vindo de Bude, em Inglaterra, e de Lannion, em França. O cabo Grace Hopper, da Google, chega a terra em Bellport, em Long Island, e transporta tráfego para Bude desde setembro de 2022.
• As bolsas saíram de Wall Street. O motor de correspondência da NYSE funciona em Mahwah, o da Nasdaq funciona em Carteret e o da Cboe funciona em Secaucus. Os operadores chamam a estes locais o triângulo das ações. As empresas que precisam de dados de mercado com latência inferior a microssegundos têm de comprar espaço junto de um deles, e essa procura financiou a fibra que hoje partilhamos.
• Os media e a publicidade estão aqui. Um leilão de publicidade em tempo real tem de devolver uma resposta antes de a página terminar de carregar. Por isso, as bolsas de publicidade foram construídas junto das redes das agências a que vendem.
• As redes vão para onde já existem redes. Quando várias centenas de carriers partilham um edifício, o seguinte obtém trânsito mais barato e melhor peering ao juntar-se a eles do que ao construir noutro local.

Para quem compra um VPS, nada disto é uma questão de prestígio. Significa que o trânsito é competitivo, o peering é denso e o caminho até à Europa é curto, porque começa onde começam os cabos.

O custo real de uma viagem de ida e volta

A luz no vidro propaga-se a cerca de 200,000 km por segundo, aproximadamente dois terços da sua velocidade no vácuo. Isso corresponde a 1 ms de tempo de ida e volta por cada 100 km de fibra, antes de qualquer router tocar no pacote. Os percursos reais são mais longos do que a distância no mapa, porque a fibra segue direitos de passagem e rotas no fundo do mar, em vez de linhas retas.

O custo não corresponde a uma única viagem de ida e volta. Corresponde ao número de viagens de ida e volta de que o protocolo precisa. Uma ligação HTTPS nova usa uma viagem de ida e volta para o handshake TCP (transmission control protocol), outra para o handshake TLS (transport layer security) 1.3 e outra para enviar o pedido e receber os primeiros bytes. São três viagens de ida e volta antes de o browser ver qualquer HTML. O TLS 1.2 acrescenta uma quarta.

[
  {
    "label": "Same metro",
    "rtt_ms": 5,
    "https_first_byte_ms": 15,
    "six_call_chain_ms": 30
  },
  {
    "label": "New York to Dallas",
    "rtt_ms": 38,
    "https_first_byte_ms": 114,
    "six_call_chain_ms": 228
  },
  {
    "label": "New York to London",
    "rtt_ms": 78,
    "https_first_byte_ms": 234,
    "six_call_chain_ms": 468
  },
  {
    "label": "New York to Singapore",
    "rtt_ms": 230,
    "https_first_byte_ms": 690,
    "six_call_chain_ms": 1380
  }
]

Essas colunas são cálculos, não medições: o primeiro byte corresponde a três viagens de ida e volta, e a coluna da cadeia representa uma página que faz seis chamadas de API dependentes, uma após outra. Dentro da área metropolitana, com 5 ms, a configuração da ligação é impercetível. Através do Atlântico, com 78 ms, a mesma página espera 234 ms antes do primeiro byte de HTML, e a cadeia de seis chamadas passa 468 ms sem fazer nada além de esperar. De Nova Iorque para Singapura, com 230 ms, essa cadeia custa 1380 ms.

Leia a coluna da cadeia antes de mover um servidor. A reutilização de ligações e a retomada de sessões TLS eliminam viagens de ida e volta que estava a pagar repetidamente. Transformar seis chamadas dependentes em duas chamadas paralelas poupa mais tempo do que aproximar um continente. Mova o servidor quando as viagens de ida e volta forem inevitáveis: num login ou numa escrita na base de dados que o cliente não consegue agrupar.

Tempos de ida e volta típicos a partir de um VPS na área metropolitana de Nova Iorque

[
  {
    "label": "Within the NY and NJ metro",
    "rtt_ms": 2
  },
  {
    "label": "Ashburn, Virginia",
    "rtt_ms": 8
  },
  {
    "label": "Toronto",
    "rtt_ms": 14
  },
  {
    "label": "Chicago",
    "rtt_ms": 22
  },
  {
    "label": "Dallas",
    "rtt_ms": 38
  },
  {
    "label": "Miami",
    "rtt_ms": 40
  },
  {
    "label": "Los Angeles",
    "rtt_ms": 70
  },
  {
    "label": "London",
    "rtt_ms": 78
  },
  {
    "label": "Frankfurt",
    "rtt_ms": 88
  },
  {
    "label": "Sao Paulo",
    "rtt_ms": 120
  }
]

Considere estes valores como números típicos publicados, não como medições feitas a partir de uma máquina específica. Este é o intervalo normalmente citado para hosts bem conectados através de trânsito comum, mas o seu próprio caminho pode apresentar valores acima ou abaixo dele. Ashburn fica a cerca de 8 ms, suficientemente perto para que um VPS em Nova Iorque aceda a serviços no cluster da Virgínia sem uma penalização significativa. Toronto fica a cerca de 14 ms. Londres fica perto de 78 ms e Frankfurt perto de 88 ms. Por isso, um servidor na costa leste pode servir utilizadores europeus com desempenho aceitável, enquanto um servidor na costa oeste não consegue fazê-lo.

Quando a localização na Costa Leste é a escolha certa

• A maioria dos seus utilizadores está no corredor entre Boston e Washington. Essa faixa concentra uma grande parte da procura de Internet dos Estados Unidos, e todos ficam a poucos milissegundos da área metropolitana.
• Você atende o leste dos Estados Unidos e a Europa a partir de uma única máquina. Nova York é o compromisso mais barato, porque a rota transatlântica começa aqui.
• Você depende de algo que já está na área metropolitana: um feed de dados de mercado, uma bolsa de publicidade ou uma API de parceiro em Secaucus ou Ashburn.
• Você quer uma rota curta para o Canadá sem hospedar o serviço lá. Toronto fica a cerca de 14 ms. Se a residência de dados no Canadá for um requisito obrigatório, essa é outra decisão, e o que realmente importa ao escolher hospedagem VPS no Canadá explica como avaliá-la.

Quando uma localização central nos EUA é melhor do que a Costa Leste

Faça o dimensionamento para o pior caso, não para a média. Um utilizador na costa oposta nota a latência. Um utilizador no estado seguinte não nota.

[
  {
    "label": "New York metro",
    "to_new_york_ms": 2,
    "to_los_angeles_ms": 70
  },
  {
    "label": "Dallas",
    "to_new_york_ms": 38,
    "to_los_angeles_ms": 35
  },
  {
    "label": "Chicago",
    "to_new_york_ms": 22,
    "to_los_angeles_ms": 50
  },
  {
    "label": "Los Angeles",
    "to_new_york_ms": 70,
    "to_los_angeles_ms": 2
  }
]

Um servidor em Nova Iorque está a 70 ms de Los Angeles. Um servidor em Dallas está a 38 ms de Nova Iorque e a 35 ms de Los Angeles, pelo que o seu pior caso entre as duas costas é aproximadamente metade do de Nova Iorque. Quando o seu mapa de tráfego é realmente nacional, essa é a localização mais vantajosa, e os argumentos para colocar um VPS em Dallas analisam esse mercado em detalhe. Chicago é a outra localização central sensata e favorece o leste.

Duas outras situações afastam a escolha de Nova Iorque. Se os seus utilizadores estiverem concentrados em Ontário ou no Quebeque, um VPS em Toronto atende-os diretamente, em vez de adicionar o salto de 14 ms a partir de Nova Iorque. E, se quase todo o seu tráfego circular entre os seus próprios servidores, mantenha-os numa só região e deixe de pensar na geografia, porque um salto entre regiões anula qualquer vantagem obtida por estar perto dos utilizadores.

Meça; não confie no mapa de marketing

Um mapa de cobertura mostra onde existe um edifício. Não mostra como os pacotes chegam a esse edifício. Esse caminho é definido por contratos de trânsito e acordos de peering, não pela distância. Por isso, faça as medições a partir do local onde os seus utilizadores estão. Um portátil numa ligação doméstica de banda larga é uma sonda melhor do que o próprio VPS, que está do lado favorável da rede.

sudo apt update
sudo apt install -y mtr-tiny traceroute iperf3

Comece com uma medição simples de ida e volta e envie vinte sondas em vez de quatro. Substitua o hostname pelo seu próprio servidor.

ping -c 20 your-server.example.com

A última linha apresenta rtt min/avg/max/mdev. A média é o número menos útil nesse resultado. mdev é o jitter, e um jitter elevado prejudica chamadas de voz e sessões interativas mesmo quando a média parece normal. Numa ligação com fios, qualquer perda de pacotes acima de zero indica uma falha, não ruído.

Depois, descubra onde o tempo é gasto.

mtr -rwzbc 100 your-server.example.com

mtr envia 100 sondas para cada salto e apresenta a perda e a latência de cada salto. -z acrescenta o número do AS (sistema autónomo), para que possa ver qual rede controla cada salto. Uma perda apresentada num salto intermédio que desaparece nos saltos seguintes não é real: esse router está a limitar a taxa das respostas ICMP que ele próprio tem de gerar, o que não afeta o seu tráfego. Uma perda que começa num salto e continua em todos os saltos seguintes é real.

O ICMP também é o protocolo errado para avaliar um serviço web, porque muitas redes atribuem-lhe baixa prioridade. Meça o serviço que efetivamente disponibiliza.

curl -o /dev/null -s -w 'dns %{time_namelookup}\ntcp %{time_connect}\ntls %{time_appconnect}\nttfb %{time_starttransfer}\ntotal %{time_total}\n' https://example.com/

Cada valor representa segundos acumulados desde o início, por isso é necessário subtraí-los para interpretar o resultado. time_connect menos time_namelookup corresponde a uma ida e volta. time_appconnect menos time_connect corresponde ao handshake TLS. time_starttransfer menos time_appconnect corresponde a mais uma ida e volta, acrescida do tempo que a aplicação demorou a responder. Esta última subtração fornece o diagnóstico. Se o resultado for próximo de uma ida e volta, a rede é o limite e um servidor mais próximo ajudará. Se for várias vezes superior ao tempo de ida e volta, a aplicação está lenta e mudá-la de localização não altera nada.

for i in $(seq 1 20); do
  curl -o /dev/null -s -w '%{time_starttransfer}\n' https://example.com/
done | sort -n | awk 'NR==10 || NR==11'

Execute o mesmo teste numa instância de avaliação em cada localização candidata antes de escolher uma. O método completo para comparar um VPS também abrange o disco e o CPU além da rede, para que não escolha apenas com base na latência.

O que mais muda com um endereço em Nova Iorque

O preço é a primeira diferença. A energia e o espaço físico na região metropolitana de Nova Iorque custam mais do que no Texas ou no Midwest. Alguns fornecedores repercutem esse custo como uma sobretaxa por localização. Outros distribuem-no pela frota. Em agosto de 2026, não existe uma regra única. Por isso, compare a mesma especificação em duas localizações na própria página de encomenda do fornecedor antes de assumir que existe uma penalização. Quanto custa realmente um VPS por mês explica o restante da fatura.

A legislação não acompanha o servidor. A SHIELD Act de Nova Iorque estabelece obrigações de notificação de violações e de adoção de salvaguardas razoáveis para qualquer entidade que detenha informações privadas sobre um residente de Nova Iorque, independentemente do local onde os dados estejam armazenados. Mover o servidor para Dallas não elimina essa obrigação. Movê-lo para Manhattan não a cria. O mesmo se aplica ao GDPR (regulamento geral sobre a proteção de dados) e aos seus utilizadores europeus. A localização é relevante quando um contrato ou uma regra setorial identifica um país. Isto é comum nos cuidados de saúde e em alguns serviços financeiros.

Os riscos relacionados com a energia e as inundações merecem um parágrafo. Quando o furacão Sandy atingiu a região em outubro de 2012, vários edifícios de operadoras em Lower Manhattan perderam o serviço porque as bombas de combustível das caves ficaram inundadas e os geradores nos pisos superiores ficaram sem combustível. Um único site em qualquer região metropolitana é um ponto único de falha. Mantenha as cópias de segurança numa rede elétrica diferente e faça pelo menos uma restauração noutro local, para confirmar que a restauração funciona.

FAQ

Um VPS em Nova Iorque é mais rápido para utilizadores europeus do que um VPS no centro dos EUA?

Sim, e por uma diferença previsível. Londres fica a cerca de 78 ms da área metropolitana de Nova Iorque, porque os cabos transatlânticos chegam a terra na costa de New Jersey e em Long Island. Um servidor em Dallas chega a Londres atravessando primeiro a costa leste, pelo que soma aproximadamente os 38 ms do percurso entre Dallas e Nova Iorque. Se uma máquina tiver de servir simultaneamente os Estados Unidos orientais e a Europa, Nova Iorque é o compromisso com menor custo.

Porque é que o meu VPS de "Nova Iorque" está efetivamente em New Jersey?

Porque é aí que existem espaço em datacenter e energia disponíveis. Edifícios de Manhattan, como o 60 Hudson Street, são hubs de interligação e não grandes salas de computação, pelo que os racks ficam em Secaucus, Weehawken, Carteret, Piscataway ou Newark. A fibra adicional acrescenta bastante menos de um milissegundo, algo que nenhuma carga de trabalho web notará. Peça a instalação exata apenas quando precisar de um cross-connect para uma rede específica dentro de um edifício específico.

Como sei se a latência é realmente o meu problema?

Execute a análise de tempos do curl e faça a subtração. A diferença entre time_appconnect e time_starttransfer corresponde a uma ida e volta na rede mais o tempo de processamento do próprio servidor. Se essa diferença for muito maior do que a ida e volta medida com ping, o atraso está dentro da sua aplicação e um datacenter mais próximo não o resolverá. Se a diferença for próxima de uma ida e volta e a página continuar lenta, conte quantos pedidos a página faz em sequência, porque cada um paga novamente o tempo de ida e volta.

Alojar o serviço em Nova Iorque altera as leis de privacidade que se aplicam a mim?

Na maioria dos casos, não. Regras como o SHIELD Act de Nova Iorque e o GDPR aplicam-se aos titulares dos dados que armazena, e não ao local onde o disco está instalado. A localização do servidor torna-se determinante quando um contrato ou uma regra setorial especifica um país, algo frequente nos setores da saúde e em partes dos serviços financeiros. Leia o requisito aplicável antes de escolher uma localização para o cumprir.

Uma CDN pode substituir um VPS bem localizado?

Para ficheiros estáticos, sim. Uma CDN (rede de distribuição de conteúdo) coloca em cache imagens e scripts perto dos seus utilizadores e elimina a maior parte da distância nesses pedidos. Não pode colocar em cache um dashboard com sessão iniciada nem uma escrita na base de dados, pelo que esses pedidos continuam a viajar até ao servidor de origem e continuam a pagar a ida e volta completa. Coloque a origem perto dos utilizadores que escrevem dados e deixe a CDN tratar do restante.