Чисто гипотетически, в каком-нить конфиге вебсервера можно нарисовать подобный запрет. Или сделать что-то ещё хорошее или не очень при обращении на определенный URL.

Иногда настройки хостинга требуют точного соблюдения владельца/группы файла и прав доступа. При обращении к "чужому" файлу/директории и при превышении привилегий доступа генерится ошибка. Довольно редко попадается. Да и неправильного владельца можно установить только кривыми руками из-под рута.

Логи вебсервера подтверждают, что 403 ошибка действительно возникает только на одном этом файле, а всё остальное успешно отдается с кодом 200?

Sputnick,

Для чистоты эксперименту есть смысл очистить кеши браузера и прокси, если таковой имеется. О наличии прозрачного кеширующего прокси-сервера (например, у провайдера) Вы можете и не знать, к сожалению.

Кеш ДНС (на компе, роутере, где-то ещё) - то же самое, очистить. Гуглевый ДНС при переездах использовать нежелательно вообще - он косячит с TTL в ряде случаев и тогда сильно сбивает с толку. Идеальный вариант для таких проблемных случаев - свой, полностью подконтрольный ДНС, который резолвит имена от . (корня) самостоятельно. А проще подождать пару дней (для зоны RU обновление может затянуться и до трех суток) пока всё устаканится и только потом разбирать оставшиеся проблемы. Именно проще, но не правильнее или лучше. :)

Вообще, для себя я выработал рекомендации при смене хостингового сервера (а этой фигней по работе приходится заниматься довольно часто):
а) заранее проверить работоспособность сайта на новом хостинге, для доступа используя технический домен хостера (обычно можно подключить алиасом) или прописав в браузере в качестве прокси IP нового сервера (последнее обычно удобнее, но не сработает при наличии прозрачного проксирования у провайдера);
б) правильно настроить и проверить новый ДНС (если предполагается его переезд к новому хостеру) - тогда смена делегирования домена пройдет вообще тихо-мирно-незаметно, а идентичные до разумной степени настройки нового и старого ДНС сократят практически до нуля вероятность появления сюрпризов;
в) заблаговременно(!) снизить TTL (время жизни) А-записей на старом и новом ДНС до каких-то 3...5 или, край, 10 минут - это для того, чтобы сайт быстро переключился на новый сервер после смены значения А-записи (и обратно на старый, если вдруг что-то пойдет ну совсем не так);
г) отключить от сайта технический домен (алиас), вернуть TTL в нормальное значение (несколько часов).