Перейти к основному содержанию

FirstVDS меняет публичные S3 URL: s3.firstvds.ru → firsts3.ru

Ичи28.08.2026ХостингХостингFirstVDSS3Object StorageМиграцияCDNОколо 4 минОколо 1064 слов

FirstVDS меняет публичные S3 URL: s3.firstvds.ru → firsts3.ru

27 августа 2026 года FirstVDS объявил о переводе публичных ссылок Object Storage на отдельный домен второго уровня.

старый hostname: s3.firstvds.ru
новый hostname:  firsts3.ru

Провайдер попросил обновить публичные ссылки до 28 августа 2026 года. На момент анонса новый домен уже работал, а со старого был настроен редирект. При этом FirstVDS отдельно предупредил, что после переходного периода старые ссылки перестанут работать.

Это не просто косметическая смена адреса. Старый hostname может быть записан в коде, базе данных, CMS, CDN-origin, переменных окружения, правилах CORS/CSP и генераторе подписанных ссылок.

Что именно меняется

FirstVDS объясняет переход желанием:

  • изолировать инфраструктуру S3;
  • улучшить балансировку;
  • повысить отказоустойчивость публичной выдачи объектов.

Формат bucket и object key нужно брать из реально сгенерированных ссылок в панели или SDK. Не стоит автоматически предполагать, что все проекты используют один и тот же path-style или virtual-hosted-style URL.

Правильная задача миграции:

найти места, где используется старый endpoint
        ↓
обновить конфигурацию и генерацию URL
        ↓
перевыпустить подписанные ссылки
        ↓
проверить чтение объектов и интеграции
        ↓
убрать зависимость от временного редиректа

Сначала найти старый hostname

В репозитории

Из корня проекта:

rg -n --hidden --glob '!.git' 's3\.firstvds\.ru' .

Если ripgrep не установлен:

grep -RIn --exclude-dir=.git 's3\.firstvds\.ru' .

Проверьте в первую очередь:

  • .env и шаблоны .env.example;
  • конфигурацию S3 SDK;
  • Laravel config/filesystems.php;
  • WordPress options и настройки плагинов offload-media;
  • Vue/Nuxt runtime config;
  • шаблоны писем и уведомлений;
  • fixtures, seeders и тестовые данные;
  • Terraform, Ansible и Helm values;
  • GitHub Actions / GitLab CI variables;
  • документацию и примеры API.

В базе данных

Поиск зависит от СУБД и схемы. Для PostgreSQL или MySQL не следует бездумно запускать массовый REPLACE по всей базе. Сначала найдите конкретные таблицы и поля, сделайте backup и посчитайте совпадения.

Пример для известного текстового поля:

SELECT id, file_url
FROM media
WHERE file_url LIKE '%s3.firstvds.ru%';

Перед заменой проверьте:

  • URL хранится целиком или собирается из endpoint и object key;
  • не является ли URL подписанным;
  • не закодирован ли адрес внутри JSON;
  • нет ли сериализованных PHP-данных WordPress, где простая замена может повредить длины строк.

Для WordPress безопаснее использовать WP-CLI или инструмент, который понимает сериализацию:

wp search-replace 's3.firstvds.ru' 'firsts3.ru' --all-tables --precise --dry-run

После проверки:

wp search-replace 's3.firstvds.ru' 'firsts3.ru' --all-tables --precise

Не заменять hostname внутри presigned URL строкой

Подписанный URL включает параметры и подпись, рассчитанную для конкретного запроса. Host может участвовать в canonical request. Поэтому механическая замена:

s3.firstvds.ru → firsts3.ru

в уже созданной presigned-ссылке способна сделать подпись недействительной.

Для подписанных URL нужно:

  1. обновить endpoint в конфигурации S3-клиента;
  2. заново сгенерировать ссылку;
  3. проверить срок действия и скачивание без авторизации;
  4. удалить или перестать выдавать старый вариант.

Если ссылки хранятся месяцами, лучше хранить bucket + object key, а публичный или подписанный URL строить при выдаче.

Проверить CDN и reverse proxy

Если S3 используется как origin для CDN, проверьте:

  • origin hostname;
  • Host header, отправляемый к origin;
  • health-check;
  • cache key;
  • origin shield;
  • правила редиректов;
  • purge/invalidation;
  • TLS/SNI;
  • allowlist исходящих адресов.

После смены origin очистите или выборочно инвалидируйте кеш только там, где это действительно нужно. Если публичный URL для пользователя не меняется, а изменился только внутренний origin, массовый purge может быть лишним.

CORS

Для загрузки или чтения S3 из браузера проверьте:

  • Access-Control-Allow-Origin;
  • разрешённые методы GET, HEAD, PUT, POST;
  • разрешённые заголовки;
  • preflight OPTIONS;
  • ExposeHeaders, если приложение читает ETag или другие метаданные.

Content Security Policy

Старый hostname может быть указан в:

  • img-src;
  • media-src;
  • connect-src;
  • font-src;
  • frame-src.

Поиск по конфигурации:

rg -n 's3\.firstvds\.ru|img-src|media-src|connect-src' nginx/ config/ .github/ deploy/

Сначала добавьте новый hostname, проверьте production, а старый удалите после завершения перехода.

Минимальная проверка новой ссылки

NEW_URL='https://...firsts3.ru/.../test-object.jpg'

curl -sS -D - -o /dev/null "$NEW_URL"
curl -sS -I "$NEW_URL"
curl -sS -H 'Range: bytes=0-99' -D - -o /dev/null "$NEW_URL"

Проверьте:

  • HTTP 200 или ожидаемый 206 для Range;
  • корректный Content-Type;
  • Content-Length;
  • ETag;
  • Cache-Control;
  • CORS-заголовки;
  • отсутствие лишней цепочки редиректов;
  • загрузку большого файла;
  • чтение объекта с пробелами и кириллицей в key;
  • корректный 404 для несуществующего объекта.

Сравнить старую и новую выдачу

Пока старый адрес ещё отвечает, полезно сравнить метаданные:

OLD_URL='https://...s3.firstvds.ru/.../test-object.jpg'
NEW_URL='https://...firsts3.ru/.../test-object.jpg'

curl -sS -L "$OLD_URL" -o /tmp/old-object
curl -sS "$NEW_URL" -o /tmp/new-object

sha256sum /tmp/old-object /tmp/new-object

Одинаковый checksum подтверждает совпадение проверенного объекта, но не заменяет проверку всего bucket или inventory.

Что делать с уже опубликованными URL

HTML, RSS, sitemap и почтовые рассылки

Обновите ссылки в:

  • HTML старых страниц;
  • RSS/Atom;
  • XML/JSON feeds;
  • sitemap для изображений и видео;
  • email-шаблонах;
  • экспортируемых CSV/XML;
  • карточках товаров и маркетплейсах.

После публикации проверьте, что поисковики и внешние сервисы получают прямой новый URL, а не зависят от временного редиректа.

Социальные сети и внешние публикации

Часть внешних ссылок изменить невозможно. Для них важно уточнить у FirstVDS срок жизни старого hostname и не считать текущий редирект бессрочной гарантией.

Новые функции S3 в августе 2026 года

В том же релизе FirstVDS добавил:

  • временные ссылки с настраиваемым сроком действия — от минут до месяцев;
  • lifecycle rules в интерфейсе;
  • автоматическое удаление объектов и незавершённых multipart uploads;
  • синхронизацию multipart upload между устройствами.

Lifecycle для незавершённых multipart uploads полезен, потому что брошенные части занимают место и могут продолжать тарифицироваться. Перед включением правила проверьте, через сколько дней ваши реальные большие загрузки гарантированно завершаются.

Checklist миграции

  • [ ] Найдено каждое использование s3.firstvds.ru в коде и конфигурации.
  • [ ] Проверены БД, CMS, письма, feeds и статический HTML.
  • [ ] Endpoint обновлён в SDK, а не только в отображаемом URL.
  • [ ] Presigned URLs перевыпускаются с новым endpoint.
  • [ ] Обновлены CDN-origin, CORS и CSP.
  • [ ] Проверены GET, HEAD, Range и большой объект.
  • [ ] Проверены изображения, документы, видео и downloads из production.
  • [ ] Настроен мониторинг 4xx/5xx по новому hostname.
  • [ ] Старый hostname удалён из конфигурации после подтверждения стабильности.
  • [ ] Есть независимая копия критичных объектов и restore-test.

Влияние на категорию

FirstVDS остаётся в категории «Норм». Переход на отдельный S3-домен сам по себе не является аварией и заявлен как инфраструктурное улучшение.

Operational-риск заключается в коротком дедлайне и возможности поломки hardcoded URL. Поэтому изменение нужно рассматривать как обязательную миграцию, а не как необязательный анонс новой функции.

Источники