Полное описание конфигурации: AppConfig/ProxyConfig, место сохранения на диск и семантика горячего обновления
Вы изменили auth_mode, но клиент всё равно получает 401; вы открыли allow_lan_access, но устройства в том же сегменте сети не могут подключиться; вы хотите мигрировать конфигурацию на новую машину, но не знаете, какие файлы нужно скопировать.
В этом уроке полностью объясняется система конфигурации Antigravity Tools: где хранятся настройки, каковы значения по умолчанию, какие из них поддерживают горячее обновление, а какие требуют перезапуска обратного прокси.
Что такое AppConfig/ProxyConfig?
AppConfig/ProxyConfig — это модели конфигурационных данных Antigravity Tools: AppConfig управляет общими настройками десктопного приложения (язык, тема, разогрев, защита квот и т. д.), ProxyConfig управляет параметрами запуска локальной службы обратного прокси (порт, аутентификация, маппинг моделей, вышестоящий прокси и т. д.). В конечном итоге они все сериализуются в один и тот же файл gui_config.json, который считывается обратным прокси при запуске, используя ProxyConfig.
Что вы сможете сделать после изучения
- Найти реальное место сохранения файла конфигурации
gui_config.jsonи создать резервную копию/выполнить миграцию - Понять основные поля и значения по умолчанию AppConfig/ProxyConfig (на основе исходного кода)
- Определить, какие настройки поддерживают горячее обновление после сохранения, а какие требуют перезапуска обратного прокси для вступления в силу
- Понять условия возникновения «миграции конфигурации» (старые поля автоматически объединяются/удаляются)
Ваша текущая проблема
- Вы изменили конфигурацию, но она «не применяется»: вы не знаете, не сохранилась ли она, не обновилась ли горячим образом, или требуется перезапуск
- Вы хотите перенести только «конфигурацию обратного прокси» на новую машину, но боитесь, что вместе с ней перенесете данные аккаунтов
- После обновления появляются старые поля, вы беспокоитесь, что формат файла конфигурации «поврежден»
Когда использовать этот подход
- Вы собираетесь переключить обратный прокси с режима «только локальный» в режим «доступ из локальной сети»
- Вы собираетесь изменить стратегию аутентификации (
auth_mode/api_key) и хотите сразу подтвердить вступление в силу - Вам нужно массово обслуживать маппинг моделей/вышестоящий прокси/конфигурацию z.ai
🎒 Подготовка перед началом
- Вы уже знаете, что такое каталог данных (см. Первый запуск: Каталог данных, журналы, трей и автозапуск)
- Вы можете запустить службу обратного прокси один раз (см. Запуск локального обратного прокси и подключение первого клиента)
Сначала о границах
В этом уроке вас научат читать/создавать резервные копии/мигрировать gui_config.json, но не рекомендуется рассматривать его как «файл конфигурации для долгосрочного ручного обслуживания». Поскольку при сохранении конфигурации на стороне бэкенда он перерериализуется в соответствии со структурой Rust AppConfig, неизвестные поля, вручную вставленные в него, скорее всего, будут автоматически удалены при следующем сохранении.
Основная идея
В вопросе конфигурации запомните три фразы:
- AppConfig — это корневой объект персистентной конфигурации, который сохраняется в
gui_config.json. - ProxyConfig — это дочерний объект
AppConfig.proxy, вокруг которого вращается запуск и горячее обновление обратного прокси. - Горячее обновление — это «только обновление состояния в памяти»: способность обновляться в горячем режиме не означает возможность изменения прослушивающего порта/адреса прослушивания.
Следуйте за мной
Шаг 1: Найдите gui_config.json (единственный источник правды конфигурации)
Почему Все ваши последующие действия по «резервному копированию/миграции/устранению неполадок» должны основываться на этом файле.
Каталог данных бэкенда — это .antigravity_tools в вашей домашней директории (будет автоматически создан, если не существует), имя файла конфигурации фиксировано как gui_config.json.
CONFIG_FILE="$HOME/.antigravity_tools/gui_config.json"
echo "$CONFIG_FILE"
ls -la "$CONFIG_FILE" || true$configFile = Join-Path $HOME ".antigravity_tools\gui_config.json"
$configFile
Get-ChildItem -Force $configFile -ErrorAction SilentlyContinueВы должны увидеть:
- Если вы еще не запускали обратный прокси, этот файл может не существовать (бэкенд будет использовать конфигурацию по умолчанию напрямую).
- При запуске службы обратного прокси или сохранении настроек он будет автоматически создан и заполнен JSON.
Шаг 2: Сначала создайте резервную копию (защита от случайных действий + удобство отката)
Почему В конфигурации могут содержаться чувствительные поля, такие как proxy.api_key, api_key z.ai и т. д. При миграции/сравнении резервная копия надежнее, чем «память».
mkdir -p "$HOME/antigravity-config-backup"
cp "$HOME/.antigravity_tools/gui_config.json" "$HOME/antigravity-config-backup/gui_config.$(date +%Y%m%d%H%M%S).json"$backupDir = Join-Path $HOME "antigravity-config-backup"
New-Item -ItemType Directory -Force -Path $backupDir | Out-Null
$ts = Get-Date -Format "yyyyMMddHHmmss"
Copy-Item (Join-Path $HOME ".antigravity_tools\gui_config.json") (Join-Path $backupDir "gui_config.$ts.json")Вы должны увидеть: в каталоге резервных копий появился JSON-файл с временной меткой.
Шаг 3: Разберитесь со значениями по умолчанию (не полагайтесь на догадки)
Почему Многие проблемы «не могу правильно настроить» на самом деле вызваны неправильными ожиданиями относительно значений по умолчанию.
Ниже приведены значения по умолчанию из AppConfig::new() и ProxyConfig::default() на стороне бэкенда:
| Блок конфигурации | Поле | Значение по умолчанию (исходный код) | Что нужно запомнить |
|---|---|---|---|
| AppConfig | language | "zh" | По умолчанию китайский |
| AppConfig | theme | "system" | Следовать за системой |
| AppConfig | auto_refresh | true | По умолчанию будет автоматически обновлять квоты |
| AppConfig | refresh_interval | 15 | Единица: минуты |
| ProxyConfig | enabled | false | По умолчанию обратный прокси не запускается |
| ProxyConfig | allow_lan_access | false | По умолчанию привязывается только к локальной машине (приоритет приватности) |
| ProxyConfig | auth_mode | "off" | По умолчанию без аутентификации (сценарий только локальной машины) |
| ProxyConfig | port | 8045 | Это поле, которое вы чаще всего меняете |
| ProxyConfig | api_key | "sk-<uuid>" | По умолчанию генерируется случайный ключ |
| ProxyConfig | request_timeout | 120 | Единица: секунды (примечание: внутри обратного прокси в текущей реализации он может не использоваться) |
| ProxyConfig | enable_logging | true | По умолчанию включен сбор журналов, от которых зависит мониторинг/статистика |
| StickySessionConfig | mode | Balance | Стратегия планирования по умолчанию — сбалансированная |
| StickySessionConfig | max_wait_seconds | 60 | Имеет смысл только в режиме CacheFirst |
Как посмотреть полные поля?
Вы можете напрямую открыть gui_config.json и сравнить с исходным кодом: src-tauri/src/models/config.rs (AppConfig) и src-tauri/src/proxy/config.rs (ProxyConfig). В конце урока «Ссылка на исходный код» даны кликабельные ссылки на номера строк.
Шаг 4: Измените конфигурацию, которая «гарантированно обновится в горячем режиме», и сразу подтвердите (на примере аутентификации)
Почему Вам нужен замкнутый цикл «изменил — сразу подтвердил», чтобы избежать слепых изменений в UI.
Когда обратный прокси работает, бэкенд save_config будет выполнять горячее обновление в памяти следующего содержания:
proxy.custom_mappingproxy.upstream_proxyproxy.auth_mode/proxy.api_key(политики безопасности)proxy.zaiproxy.experimental
В качестве примера здесь используется auth_mode:
- Откройте страницу
API Proxy, убедитесь, что служба обратного прокси находится в состоянии Running. - Установите
auth_modeвall_except_healthи убедитесь, что вы знаете текущийapi_key. - Используйте следующий запрос для подтверждения «пропуск проверки работоспособности, перехват других интерфейсов».
# Запрос /healthz без ключа: должен быть успешным
curl -sS "http://127.0.0.1:8045/healthz" && echo
# Запрос /v1/models без ключа: должен быть 401
curl -sS -i "http://127.0.0.1:8045/v1/models"
# Повторный запрос /v1/models с ключом: должен быть успешным
curl -sS -H "Authorization: Bearer <proxy.api_key>" "http://127.0.0.1:8045/v1/models"# Запрос /healthz без ключа: должен быть успешным
Invoke-WebRequest -UseBasicParsing "http://127.0.0.1:8045/healthz" | Select-Object -ExpandProperty StatusCode
# Запрос /v1/models без ключа: должен быть 401
try { Invoke-WebRequest -UseBasicParsing "http://127.0.0.1:8045/v1/models" } catch { $_.Exception.Response.StatusCode.value__ }
# Повторный запрос /v1/models с ключом: должен быть успешным
$headers = @{ Authorization = "Bearer <proxy.api_key>" }
(Invoke-WebRequest -UseBasicParsing "http://127.0.0.1:8045/v1/models" -Headers $headers).StatusCodeВы должны увидеть: /healthz возвращает 200; /v1/models без ключа возвращает 401, с ключом — успешно.
Шаг 5: Измените конфигурацию, которая «требует перезапуска обратного прокси» (порт / адрес прослушивания)
Почему Многие настройки «сохранены, но не применены», корневая причина — не ошибка, а то, что они определяют, как привязывается TCP Listener.
При запуске обратного прокси бэкенд будет вычислять адрес прослушивания (127.0.0.1 или 0.0.0.0) с помощью allow_lan_access и привязывать порт с помощью port; этот шаг происходит только в start_proxy_service.
Рекомендации по действиям:
- На странице
API Proxyизменитеportна новое значение (например,8050) и сохраните. - Остановите службу обратного прокси, затем перезапустите.
- Подтвердите
/healthzновым портом.
curl -sS "http://127.0.0.1:8050/healthz" && echoInvoke-WebRequest -UseBasicParsing "http://127.0.0.1:8050/healthz" | Select-Object -ExpandProperty StatusCodeВы должны увидеть: новый порт доступен; старый порт недоступен или возвращает пустой ответ.
О allow_lan_access
В исходном коде allow_lan_access одновременно влияет на две вещи:
- Адрес прослушивания: определяет, привязываться к
127.0.0.1или0.0.0.0(требует перезапуска обратного прокси для повторного bind). - Автоматическая стратегия аутентификации: когда
auth_mode=auto, в сценарии локальной сети он автоматически переключается наall_except_health(эта часть поддерживает горячее обновление).
Шаг 6: Поймите «миграцию конфигурации» (старые поля будут автоматически очищены)
Почему После обновления вы можете увидеть старые поля в gui_config.json и беспокоиться, что «повреждено». На самом деле при загрузке конфигурации бэкенд выполнит миграцию: объединит anthropic_mapping/openai_mapping в custom_mapping и удалит старые поля, затем автоматически сохранит один раз.
Вы можете использовать эту закономерность для самопроверки:
- Если вы видите в файле
proxy.anthropic_mappingилиproxy.openai_mapping, после следующего запуска/загрузки конфигурации они будут удалены. - При объединении пропускаются ключи, оканчивающиеся на
-series(эти теперь обрабатываются логикой preset/builtin).
Вы должны увидеть: после миграции в gui_config.json остается только proxy.custom_mapping.
Контрольная точка ✅
- Вы можете найти
$HOME/.antigravity_tools/gui_config.jsonна локальной машине - Вы можете объяснить, почему такие конфигурации, как
auth_mode/api_key/custom_mapping, поддерживают горячее обновление - Вы можете объяснить, почему такие конфигурации, как
port/allow_lan_access, требуют перезапуска обратного прокси
Напоминания о возможных ошибках
- Горячее обновление
save_configохватывает только небольшое количество полей: оно не поможет вам перезапустить listener и не отправит такие конфигурации, какscheduling, в TokenManager. request_timeoutв текущей реализации обратного прокси не действительно вступает в силу: параметр_request_timeoutвstartAxumServer, а в состоянии тайм-аут жестко задан как300секунд.- Ненадежно вручную добавлять «пользовательские поля» в
gui_config.json: при сохранении конфигурации на стороне бэкенда он будет перерериализован вAppConfig, неизвестные поля будут отброшены.
Краткое содержание урока
- Конфигурация сохраняется в одном месте:
$HOME/.antigravity_tools/gui_config.json - «Способность ProxyConfig поддерживать горячее обновление» не равна «возможности изменения порта/адреса прослушивания»; всё, что связано с bind, требует перезапуска обратного прокси
- Если вы видите старые поля маппинга, не паникуйте: при загрузке конфигурации они автоматически мигрируют в
custom_mappingи старые поля очищаются
Предварительный просмотр следующего урока
Следующий урок мы изучим Безопасность и приватность: auth_mode, allow_lan_access и проект «не раскрывать информацию об аккаунтах».
Вы узнаете:
- Когда обязательно нужно включать аутентификацию (и почему
autoв сценарии локальной сети более строгий)- Минимальную стратегию раскрытия при открытии локального обратного прокси в локальную сеть/общественную сеть
- Какие данные отправляются на вышестоящий уровень, а какие хранятся только локально
Приложение: Ссылка на исходный код
Нажмите, чтобы развернуть и просмотреть местоположение исходного кода
Дата обновления: 2026-01-24
| Тема | Путь к файлу | Номер строки |
|---|---|---|
Значения по умолчанию AppConfig (AppConfig::new()) | src-tauri/src/models/config.rs | 4-158 |
| Значения по умолчанию ProxyConfig (порт/аутентификация/адрес прослушивания) | src-tauri/src/proxy/config.rs | 74-292 |
| Значения по умолчанию StickySessionConfig (планирование) | src-tauri/src/proxy/sticky_config.rs | 3-36 |
Имя файла сохранения конфигурации + логика миграции (gui_config.json) | src-tauri/src/modules/config.rs | 7-88 |
Каталог данных ($HOME/.antigravity_tools) | src-tauri/src/modules/account.rs | 16-33 |
save_config: сохранение конфигурации + горячее обновление каких полей | src-tauri/src/commands/mod.rs | 296-334 |
AxumServer: update_mapping/update_proxy/update_security/... | src-tauri/src/proxy/server.rs | 45-117 |
Выбор адреса прослушивания allow_lan_access | src-tauri/src/proxy/config.rs | 81-92 |
| Привязка адреса и порта при запуске Proxy (меняется только после перезапуска) | src-tauri/src/commands/proxy.rs | 42-134 |
Фактические правила auth_mode=auto | src-tauri/src/proxy/security.rs | 3-31 |
| Сохранение конфигурации планирования на стороне фронтенда (только сохранение, не отправка в бэкенд рантайма) | src/pages/ApiProxy.tsx | 476-501 |
| Монитор страницы динамическое включение/выключение сбора журналов | src/components/proxy/ProxyMonitor.tsx | 174-263 |