Voltar ao blog
·9 min de leitura·productdevbook

Como monitorar o uso de Wi-Fi por aplicativo no Mac

Como ver o uso de Wi-Fi por aplicativo no Mac em tempo real e ao longo do tempo, sem pagar mensalidade SaaS pelo privilégio.

  • macOS
  • Wi-Fi
  • Bandwidth
  • Tutorial

Você está num Wi-Fi de hotel, a conexão parece mais lenta do que deveria, e você não faz ideia de qual app está dominando o link. Activity Monitor vai te dizer bytes-in e bytes-out por processo, mas não te diz se aqueles bytes passaram por Wi-Fi ou ethernet — ou em qual rede você estava na hora. Para monitorar uso de Wi-Fi por app no Mac, você precisa entender como o macOS conta tráfego por processo, como roteia esses bytes pelas interfaces e como surfacear esses dados sem deixar um app pesado rodando o dia todo.

Este guia percorre o que "uso de Wi-Fi" realmente significa no macOS, as ferramentas built-in que você pode usar hoje e como um monitor na barra de menu transforma os mesmos dados de kernel em algo que você consegue olhar de relance enquanto trabalha.

O que "monitorar uso de Wi-Fi por app no Mac" de fato significa

O macOS não rastreia Wi-Fi separadamente do ethernet na camada de aplicação. Cada app abre sockets, o kernel roteia pacotes pela interface (en0, en1, utun0, etc.) que é a rota padrão atual, e contadores por processo somam bytes independente de qual link físico carregou.

Então quando pessoas buscam como monitorar uso de Wi-Fi por app num Mac, quase sempre querem dizer uma de duas coisas:

  1. Tráfego por app enquanto meu Mac está em Wi-Fi — i.e., estou num café, ethernet desplugado, então todo tráfego passa em en0. Nesse caso, "tráfego por app" e "tráfego Wi-Fi por app" são a mesma coisa.
  2. Tráfego por app especificamente roteado pela interface Wi-Fi mesmo quando outras interfaces existem. Isso importa num Mac mini com adaptador ethernet USB, ou quando você está em tethering com hotspot de telefone.

Ambas perguntas se reduzem a: "me mostre bytes por processo e me diga qual interface usaram". Apple entrega respostas parciais no nettop e no Activity Monitor. Uma ferramenta dedicada preenche o vão.

Como o macOS roteia tráfego entre Wi-Fi e ethernet

Abra Ajustes do Sistema → Rede. Você verá uma lista de serviços em ordem de prioridade: Wi-Fi, USB 10/100/1000 LAN, Thunderbolt Bridge e por aí. O serviço ativo no topo ganha para conexões novas, a menos que um app ligue explicitamente em outra interface.

Algumas coisas seguem disso:

  • Se ethernet e Wi-Fi estão conectados, e ethernet está mais alto na ordem de serviço, quase nada flui em Wi-Fi até você desplugar.
  • Apps em segundo plano que abriram conexão enquanto você estava em Wi-Fi vão manter na Wi-Fi até reconectarem. Então mudar para ethernet não move imediatamente o sync iCloud — a próxima reconexão sim.
  • Túneis VPN (utun*) embrulham a interface subjacente. Bytes aparecem em utun0 e na interface física que carrega o túnel.

Você pode confirmar a interface padrão atual com route get default no Terminal — vai imprimir interface: en0 (Wi-Fi) ou interface: en6 (USB ethernet) ou similar.

Ferramentas built-in: nettop e Activity Monitor

Antes de buscar algo novo, tente as ferramentas que já estão no seu Mac.

nettop

Abra o Terminal e rode:

nettop -P -m route

-P soma por processo (em vez de por conexão) e -m route muda para visão agrupada por rota. Você vai ver linhas como Slack.21341 com bytes_in e bytes_out atualizando ao vivo. Pressione c para mudar modos, q para sair.

Limites: nettop não consegue prender contadores numa única interface dentro da visão padrão, e não agrupa processos auxiliares. Você vai ver Slack, Slack Helper, Slack Helper (GPU) e Slack Helper (Renderer) como quatro linhas separadas.

Activity Monitor — aba Rede

A aba Rede do Activity Monitor mostra bytes totais enviados e recebidos por processo desde que o processo iniciou. Não mostra taxa ao vivo, não agrupa helpers e não separa interfaces. Útil como sanity check, não como ferramenta em tempo real.

Dados específicos de Wi-Fi: wdutil

sudo wdutil info

imprime o estado da camada de link — canal, RSSI, modo PHY, BSSID. Combinado com contadores por app, te diz se a lentidão é problema de rádio ou de app.

Por que uma ferramenta na barra de menu para monitorar uso de Wi-Fi por app no Mac ganha

Rodar nettop numa janela do Terminal o dia todo não é fluxo ótimo. Você quer um relance, não uma sessão. É aí que entra um monitor de barra de menu.

ova fica na barra de menu do macOS e mostra taxas up/down ao vivo por padrão. Clique e você ganha uma lista por app com taxa atual mais uma linha do tempo navegável de uso histórico. Processos auxiliares — Slack Helper, Google Chrome Helper, Discord Helper — são agrupados sob o app pai, então você lê "Slack" em vez de sete linhas de helper.

Quando seu Mac está conectado só por Wi-Fi, essa lista por app é seu detalhamento de uso Wi-Fi. Quando você tem múltiplas interfaces, você pode correlacionar a linha do tempo com qual interface estava ativa.

Agrupamento de processos auxiliares
ova agrupa cada PID auxiliar sob o app pai para que a lista por app leia limpa. Sem mais rolar por quatro entradas "Google Chrome Helper" para achar o Spotify.

Um setup de 5 minutos para ver uso de Wi-Fi por app hoje

Aqui um workflow repetível que você pode rodar agora.

  1. Confirme que Wi-Fi é a interface ativa. No Terminal: route get default. Procure interface: en0 (ou o que seu Wi-Fi mostra em Ajustes do Sistema → Rede).
  2. Instale um monitor de barra de menu. Solte o ova em /Applications. Cerca de 3 MB, assinado e notarizado, roda em macOS 14 e posteriores.
  3. Abra a lista da barra de menu. Você vai ver taxa ao vivo por app. Ordene por taxa atual para achar o tagarela.
  4. Navegue a linha do tempo. Clique na visão histórica para ver se um app deu pico cinco minutos atrás, uma hora atrás, ou esteve constante a manhã toda.
  5. Cruze com nettop. Se um número parece suspeito, rode nettop -P -m route e compare. Os dois devem concordar de perto — leem os mesmos contadores de kernel.

Veja o ova em ação

Um monitor de banda na barra de menu para olhar de relance — local, assinado, ~3 MB.

Baixar para macOS

Lendo os dados: o que é normal, o que não é

Algumas linhas de base de um dia de trabalho típico em Wi-Fi:

  • Slack idle: 5–30 KB/s em estado estacionário, pings de websocket mais atualizações de presença. Mais alto durante huddle ou quando alguém compartilha arquivo.
  • Chrome com 10 abas: muito variável, frequentemente 0–200 KB/s idle, picos para 5+ MB/s quando um vídeo toca ou um sync Drive aciona.
  • Streaming Spotify: ~150–300 KB/s na qualidade padrão, ~700 KB/s em lossless.
  • Zoom 1080p: 2,5–3,8 Mbps up e down para 1:1, mais para gallery view.
  • Sync iCloud Photos depois de import do telefone: pode saturar seu uplink por minutos.

Se você vê tráfego sustentado de um app que não tem motivo para tagarelar — protetor de tela, atualizador de wallpaper, calculadora — isso é flag para investigar.

Quando contabilidade por interface de fato importa

A maior parte dos usuários de Mac tem uma interface ativa por vez. Mas há casos reais onde você precisa de granularidade por interface:

  • Você paga por gigabyte num hotspot. Quer saber quanto foi pelo tether do iPhone (en4 ou similar) versus Wi-Fi normal.
  • Você está numa VPN corporativa. Tráfego em utun0 é sensível a split-tunnel — você quer ver quais apps de fato usaram o túnel.
  • Você tem um Mac mini servidor com link duplo. Wi-Fi para management, ethernet para a carga, e precisa confirmar que nada vazou pelo lado errado.

O kernel expõe contadores por interface via sysctl net.link.generic e via getifaddrs(3), mas mapear de volta a processos exige caminhar bindings PID-para-socket-para-interface. É exatamente o que o nettop faz internamente, e o que um bom monitor de barra de menu como o ova surfacea numa UI para olhar de relance.

Considerações de privacidade

Um monitor de rede lê metadados — bytes por processo, hostnames em algumas ferramentas, timestamps. Isso é sensível. Antes de instalar qualquer coisa, cheque três coisas:

  1. Onde os dados ficam? Um monitor que envia seu histórico de banda para um dashboard de nuvem está exportando seu comportamento. Procure "todos os dados em disco" ou "100% local" na descrição.
  2. O app é assinado e notarizado? O Gatekeeper do macOS te diz no primeiro lançamento. Um monitor não assinado com acesso de kernel não é coisa que você quer rodar.
  3. Exige conta? Não deveria precisar. Um monitor local não precisa de credenciais de login.

ova é só local, assinado e notarizado, e nunca pede conta. Se decidir que não é para você, o reembolso de 14 dias é incondicional.

Perguntas comuns

Little Snitch já não faz isso?

Little Snitch é um firewall — seu trabalho é bloquear ou permitir conexões. Também mostra tráfego, mas o foco são regras, não métricas. ova é um monitor — seu trabalho é te mostrar o que está acontecendo, sem camada de bloqueio. Combinam bem. Rode o Little Snitch quando quer impor política. Rode o ova quando quer leitura quieta e precisa.

E quanto a uso Wi-Fi no iPhone?

SO diferente, APIs diferentes. iOS expõe dados celulares por app em Configurações → Celular mas não expõe dados Wi-Fi por app a ninguém, incluindo apps de terceiros. Não há equivalente de nettop no iOS. Foi mal.

O ova funciona no macOS 13 ou anterior?

ova exige macOS 14 (Sonoma) ou posterior. Versões anteriores não têm algumas das APIs de rede por processo que o app usa para contabilidade precisa.

Encerrando

Para monitorar uso de Wi-Fi por app no Mac, você empilha duas perguntas: contabilidade por processo mais consciência por interface. O macOS te dá os dados crus pelo nettop e pelo kernel; o Activity Monitor te dá um snapshot; um monitor de barra de menu transforma os mesmos números numa visão ao vivo, navegável, que não exige uma janela do Terminal.

Se você só fizer uma coisa hoje, instale o ova, deixe rodando por uma hora enquanto trabalha e cheque a lista por app. Os tagarelas vão te surpreender — sempre surpreendem.