Безопасность и приватность: auth_mode, allow_lan_access, а также проект «не раскрывать информацию об учётных записях»
Когда вы используете Antigravity Tools как «локальный AI-шлюз», вопросы безопасности обычно вращаются вокруг двух вещей: кому вы предоставили службу (только локальной машине, или всей локальной сети/общественной сети), а также нужно ли внешним запросам API Key. В этом уроке будут чётко объяснены правила в исходном коде, а также вам будет предоставлен минимальный базовый комплект безопасности, который вы можете напрямую использовать.
Что вы сможете сделать после изучения
- Правильно выбрать
allow_lan_access: знать, что он влияет на адрес прослушивания (127.0.0.1против0.0.0.0) - Правильно выбрать
auth_mode: понять фактическое поведение 4 режимовoff/strict/all_except_health/auto - Настроить
api_keyи проверить: с помощьюcurlсразу увидеть, «включена ли аутентификация» - Понять границы защиты конфиденциальности: локальный proxy key не будет пересылаться на вышестоящий уровень; ошибки API клиентов избегают раскрытия почты учётной записи
Ваша текущая проблема
- Вы хотите, чтобы мобильный телефон/другой компьютер могли получить доступ, но боитесь, что открытие доступа в локальную сеть приведёт к «голому пробегу»
- Вы хотите включить аутентификацию, но не уверены, нужно ли
/healthzделать исключением, боитесь, что пробное действие приведёт к сбою проверки - Вы беспокоитесь, что локальный key, cookie, почта учётной записи будут раскрыты внешнему клиенту или вышестоящему провайдеру
Когда использовать этот подход
- Вы собираетесь открыть
allow_lan_access(NAS, домашняя локальная сеть, внутренняя сеть команды) - Вы используете cloudflared/обратный прокси, чтобы открыть локальную службу в общественную сеть (сначала посмотрите Cloudflared туннель в один клик)
- Вы встретили
401, и нужно подтвердить: «это не был ключ» или «режим не выровнен»
🎒 Подготовка перед началом
Предварительные требования
- Вы уже умеете запускать API Proxy в GUI (если ещё не пройдено, сначала посмотрите Запуск локального обратного прокси и подключение первого клиента)
- Вы знаете проблему, которую хотите решить: только локальный доступ, или локальная сеть/общественная сеть
В этом уроке будут часто встречаться 3 поля
allow_lan_access: разрешать ли доступ из локальной сети.auth_mode: стратегия аутентификации (определяет, какие маршруты должны нести ключ, а также то, освобождён ли/healthz).api_key: API Key локального прокси (используется только для локальной аутентификации прокси, не будет пересылаться на вышестоящий уровень).
Что такое auth_mode?
auth_mode — это «переключатель + стратегия исключения» аутентификации Antigravity Tools. Он определяет, должны ли внешние клиенты при доступе к конечным точкам локального прокси нести proxy.api_key, а также то, разрешена ли безаутентификационная проверка для маршрутов типа /healthz.
Основная идея
- Сначала определите «поверхность раскрытия»: когда
allow_lan_access=falseслушается только127.0.0.1; когдаtrue—0.0.0.0. - Затем определите «ключ входа»:
auth_modeопределяет, нужен ли ключ, и то, освобождён ли/healthz. - Наконец, выполните «сужение приватности»: не пересылать локальный proxy key/cookie на вышестоящий уровень; в ошибках для внешних API клиентов по возможности избегать почты учётной записи.
Следуйте за мной
Шаг 1: Сначала решите, нужно ли открывать доступ из локальной сети (allow_lan_access)
Почему Вы должны открывать доступ из локальной сети только тогда, когда вам нужно, чтобы другие устройства получали доступ, в противном случае режим только локальной машины — это самый простой и безопасный вариант конфигурации безопасности.
В ProxyConfig адрес прослушивания определяется allow_lan_access:
pub fn get_bind_address(&self) -> &str {
if self.allow_lan_access {
"0.0.0.0"
} else {
"127.0.0.1"
}
}На странице API Proxy в GUI, установите переключатель «Разрешить доступ из локальной сети» в соответствии с вашими потребностями.
Вы должны увидеть
- При закрытии: текст подсказки в значении «только локальный доступ» (конкретная формулировка зависит от языкового пакета)
- При открытии: интерфейс покажет отчётливое предупреждение о риске (напоминание, что это «расширение поверхности раскрытия»)
Шаг 2: Выберите auth_mode (сначала попробуйте auto)
Почемуauth_mode — это не только «включить/выключить аутентификацию», он также определяет, освобождены ли такие маршруты пробного действия, как /healthz.
Проект поддерживает 4 режима (из docs/proxy/auth.md):
off: все маршруты не требуют аутентификацииstrict: все маршруты требуют аутентификациюall_except_health: кроме/healthz, другие маршруты требуют аутентификациюauto: автоматический режим, который выводит фактическую стратегию на основеallow_lan_access
Логика вывода auto находится в ProxySecurityConfig::effective_auth_mode():
match self.auth_mode {
ProxyAuthMode::Auto => {
if self.allow_lan_access {
ProxyAuthMode::AllExceptHealth
} else {
ProxyAuthMode::Off
}
}
ref other => other.clone(),
}Рекомендуемый подход
- Только локальный доступ:
allow_lan_access=false+auth_mode=auto(в конечном итоге эквивалентноoff) - Доступ из локальной сети:
allow_lan_access=true+auth_mode=auto(в конечном итоге эквивалентноall_except_health)
Вы должны увидеть
- На странице
API Proxyв выпадающем списке «Auth Mode» есть 4 опции:off/strict/all_except_health/auto
Шаг 3: Подтвердите ваш api_key (при необходимости перегенерируйте)
Почему Пока прокси должен быть доступен внешне (локальная сеть/общественная сеть), api_key следует управлять как паролем.
По умолчанию ProxyConfig::default() генерирует key в формате sk-...:
api_key: format!("sk-{}", uuid::Uuid::new_v4().simple()),На странице API Proxy вы можете редактировать, перегенерировать, копировать текущий api_key.
Вы должны увидеть
- На странице есть поле ввода
api_key, а также кнопки редактирования/перегенерации/копирования
Шаг 4: Проверьте с помощью /healthz стратегию исключения
Почему/healthz — это самый короткий замкнутый цикл: вам не нужно действительно вызывать модель, чтобы подтвердить «служба доступна + стратегия аутентификации верна».
Замените <PORT> на ваш порт (по умолчанию 8045):
curl -sS "http://127.0.0.1:<PORT>/healthz"curl.exe -sS "http://127.0.0.1:<PORT>/healthz"Вы должны увидеть
{"status":"ok"}Если вы установили auth_mode в strict
strict не освобождает /healthz. Вам нужно добавить ключ:
curl -sS "http://127.0.0.1:<PORT>/healthz" \
-H "Authorization: Bearer <API_KEY>"Шаг 5: Проверьте не-health маршрут, используя простой заголовок (сначала не используйте сложные SDK)
Почему Промежуточное ПО сначала читает Authorization, затем x-api-key, и в конце x-goog-api-key. Если вы отправили несколько заголовков одновременно, и первый ошибся, даже если второй правильный, он не будет использован.
# Рекомендуемый способ: Authorization + Bearer
curl -i http://127.0.0.1:<PORT>/v1/models \
-H "Authorization: Bearer sk-REPLACE_WITH_YOUR_PROXY_API_KEY"Вы должны увидеть: HTTP/1.1 200 OK (или хотя бы больше не 401)
Подробности совместимости Authorization
auth_middleware() выполнит удаление префикса Bearer от значения Authorization; если нет префикса Bearer , всё значение будет использовано как key для сопоставления. В документации по-прежнему рекомендуется Authorization: Bearer <key> (более соответствует универсальным соглашениям SDK).
Если вы должны использовать x-api-key:
curl -i http://127.0.0.1:<PORT>/v1/models \
-H "x-api-key: sk-REPLACE_WITH_YOUR_PROXY_API_KEY"Контрольная точка ✅
- Вы можете чётко сказать, какова ваша текущая поверхность раскрытия: только локальная машина (
127.0.0.1) или локальная сеть (0.0.0.0) - При
auth_mode=autoвы можете предсказать фактический действующий режим (LAN →all_except_health, локальная машина →off) - Вы можете воспроизвести «401 без ключа» с помощью 2 команд
curl
Напоминания о возможных ошибках
Неправильный против рекомендуемого подхода
| Сценарий | ❌ Частая ошибка | ✓ Рекомендуемый подход |
|---|---|---|
| Нужен доступ из локальной сети | Только открыть allow_lan_access=true, но auth_mode=off | Использовать auth_mode=auto, и установить сильный api_key |
| Включена аутентификация, но постоянно 401 | Клиент несёт ключ, но имя заголовка несовместимо | Прокси совместим с тремя видами заголовков: Authorization/x-api-key/x-goog-api-key |
| Включена аутентификация, но key не настроен | api_key пустой, аутентификация включена | Бэкенд напрямую откажет (в журналах будет подсказка, что key пуст) |
Исключение /healthz действует только в all_except_health
Промежуточное ПО освободит маршрут при «эффективном режиме» all_except_health и пути /healthz. Считайте это «пробным входом», не используйте его как бизнес-API.
Приватность и проект «не раскрывать информацию об учётных записях»
1) Локальный proxy key не будет пересылаться на вышестоящий уровень
Аутентификация происходит только на входе локального прокси; docs/proxy/auth.md явно объясняет: proxy API key не будет пересылаться на вышестоящий уровень.
2) При пересылке в z.ai будет намеренно сужен набор пересылаемых заголовков
Когда запрос пересылается в z.ai (совместимость с Anthropic), код пропустит только небольшой набор заголовков, избегая переноса локального proxy key или cookie:
// Only forward a conservative set of headers to avoid leaking local proxy key or cookies.3) Ошибка при обновлении token избегает раскрытия почты учётной записи
При неудачном обновлении Token в журналах будет записана конкретная учётная запись, но ошибка, возвращаемая клиенту API, будет перезаписана без почты:
// Avoid leaking account emails to API clients; details are still in logs.
last_error = Some(format!("Token refresh failed: {}", e));Краткое содержание урока
- Сначала определите поверхность раскрытия (
allow_lan_access), затем определите ключ входа (auth_mode+api_key) - Правило
auth_mode=autoочень простое: LAN → минимумall_except_health, только локальная машина →off - База приватности — «локальный key не向外带, почта учётной записи не向外报错 раскрыт», детали в промежуточном ПО и коде пересылки
Предварительный просмотр следующего урока
Следующий урок мы рассмотрим Высокодоступное планирование: ротация, фиксированная учётная запись, липкая сессия и повторные попытки при сбоях, дополняя «безопасный вход» «стабильным выходом».
Приложение: Ссылка на исходный код
Нажмите, чтобы развернуть и просмотреть местоположение исходного кода
Дата обновления: 2026-01-23
| Функция | Путь к файлу | Номер строки |
|---|---|---|
| 4 режима auth_mode и значение auto | docs/proxy/auth.md | 10-24 |
| Перечисление ProxyAuthMode и значение по умолчанию (по умолчанию off) | src-tauri/src/proxy/config.rs | 5-18 |
| Ключевые поля ProxyConfig: allow_lan_access/auth_mode/api_key и значения по умолчанию | src-tauri/src/proxy/config.rs | 174-258 |
| Вывод адреса прослушивания (127.0.0.1 против 0.0.0.0) | src-tauri/src/proxy/config.rs | 281-292 |
| Вывод auto → effective_auth_mode | src-tauri/src/proxy/security.rs | 10-30 |
| Промежуточное ПО аутентификации (совместимость заголовков + исключение /healthz + пропуск OPTIONS) | src-tauri/src/proxy/middleware/auth.rs | 14-77 |
| UI: переключатель allow_lan_access и выпадающий список auth_mode | src/pages/ApiProxy.tsx | 943-1046 |
| UI: редактирование/перезагрузка/копирование api_key | src/pages/ApiProxy.tsx | 1048-1120 |
| invalid_grant автоматически отключается и «избегает раскрытия почты» | src-tauri/src/proxy/token_manager.rs | 841-940 |
| disable_account: запись disabled/disabled_at/disabled_reason и удаление из пула памяти | src-tauri/src/proxy/token_manager.rs | 942-969 |
| При пересылке в z.ai сужается набор пересылаемых заголовков (избегает утечки локального key/cookies) | src-tauri/src/proxy/providers/zai_anthropic.rs | 70-89 |
| Объяснение отключения учётной записи пула в UI | docs/proxy/accounts.md | 9-44 |
Ключевое перечисление:
ProxyAuthMode::{Off, Strict, AllExceptHealth, Auto}: режимы аутентификации
Ключевая функция:
ProxySecurityConfig::effective_auth_mode(): выводитautoв реальную стратегиюauth_middleware(): выполнить аутентификацию (включая порядок извлечения заголовков + исключение /healthz)