Obter configuração de proxy da instância

A uazapiGO distingue a intenção persistida do cliente (mode) do transporte efetivo em runtime (effective_mode). Isso evita degradar silenciosamente para conexão direta quando a instância foi configurada para usar proxy.

mode sempre será:

• custom: o cliente escolheu um proxy próprio;
• internal: a instância deve usar o pool interno ou a rota interna; ou
• none: o cliente confirmou explicitamente que aceita conexão direta.

effective_mode mostra o que está sendo usado no momento:

• custom
• internal
• direct

effective_detail qualifica o transporte efetivo:

• managed_pool: proxy interno gerenciado pela plataforma;
• internal_route: rota interna dedicada do ambiente, sem uma proxy_url própria;
• relay: túnel relay do cliente;
• campo omitido: sem detalhe adicional.

Quando um proxy customizado falha, a plataforma pode seguir uma cadeia de contingência:

1. proxy_fallback explícito, se configurado com outra URL;
2. proxy interno;
3. conexão direta como último recurso, quando a política permitir.

Em qualquer fallback, a intenção persistida continua sendo mode=custom. O cliente deve olhar effective_mode, effective_detail e fallback.active para entender o estado runtime.

Como ler cada campo da resposta:

• mode: intenção salva na instância. É o que o cliente pediu para usar.
• effective_mode: transporte realmente em uso agora. Pode divergir de mode durante fallback.
• effective_detail: detalhe extra do transporte efetivo. Use para distinguir pool interno, rota interna ou relay. Quando não há detalhe adicional, o campo é omitido.
• fallback.active: true quando a instância está operando fora da rota principal configurada.
• fallback.reason: motivo interno resumido do fallback atual. Serve para diagnóstico e pode mudar conforme a causa.
• fallback.since: timestamp Unix em milissegundos desde quando o fallback atual começou.
• proxy_url: proxy persistido na instância, sempre mascarado. Se mode=custom, continua mostrando o proxy do cliente mesmo quando a sessão caiu em fallback.
• proxy_fallback: política persistida de contingência para mode=custom. Pode ser internal, never ou outra URL de proxy.
• managed: campo legado. Fica true quando a infraestrutura interna da plataforma está envolvida no transporte atual ou pretendido.
• last_test_at: timestamp Unix em milissegundos do último teste ou da última falha persistida para esse proxy.
• last_test_error: último erro persistido para diagnóstico. String vazia significa ausência de erro salvo.
• validation_error: atalho booleano para last_test_error != "".

Leitura rápida dos cenários mais comuns:

• mode=custom + effective_mode=custom: o proxy do cliente está sendo usado normalmente.
• mode=custom + effective_mode=internal: o proxy do cliente falhou e a sessão está operando no fallback interno.
• mode=custom + effective_mode=direct: o proxy do cliente falhou e a sessão caiu para conexão direta como último recurso.
• mode=internal + effective_detail=managed_pool: a instância está usando um proxy do pool interno.
• mode=internal + effective_detail=internal_route: a instância está usando uma rota interna dedicada, sem proxy_url própria.
• mode=none + effective_mode=direct: conexão direta assumida explicitamente.

Combinações que não devem aparecer numa resposta válida:

• mode=none com effective_mode=custom ou internal
• effective_detail=managed_pool com effective_mode=custom
• effective_detail=relay com effective_mode=internal ou direct