Локальный WSDL всё равно может отправить SoapClient в сеть
Отслеживайте транзитивные импорты WSDL и XML Schema, когда локальное описание сервиса всё ещё смешивает внутренние и внешние proxy-маршруты.
Локальный service.wsdl всё ещё может заставить SoapClient загружать удалённые документы во время создания. Локализация первого файла убирает только эту первую загрузку:
local service.wsdl
→ internal Common.xsd
→ external Types.xsd
→ another schema location
Начните с первой неудачной загрузки, до первого бизнес-вызова SOAP. Перечислите каждый импорт WSDL и каждое расположение schema, включая документы, на которые они, в свою очередь, ссылаются. Сохраняйте базовый URL или путь, используемый для разрешения каждой относительной ссылки. Отделяйте внутренние хосты от ресурсов, которым действительно нужен внешний proxy.
Явный proxy SoapClient может отправить внутреннюю schema через посредника с другим представлением DNS или другой политикой доступа. Переменная no_proxy уровня процесса не доказывает, что этот путь загрузки её читает. Используйте опции, задокументированные для вашей версии PHP; название опции в честь переменной окружения не создаёт селектор для каждого импорта.
Чтобы полностью разместить описания локально, получите утверждённые версии всего набора зависимостей, обновите соответствующие места импорта на локальный пакет и сохраните их базы относительных путей. Версионируйте эти документы вместе, чтобы новый корневой WSDL не использовал устаревшие типы.
Не трогайте идентификаторы пространств имён. Они могут выглядеть как URL, но определяют словарь schema, а не сообщают загрузчику, откуда брать файл. Их замена может изменить контракт сервиса.
Повторно проверьте создание с зафиксированным состоянием кеша: кешированные описания могут скрывать отсутствующую зависимость на одной машине. Переопределение URL сервиса действует на более позднем этапе, а пользовательский __doRequest() обрабатывает обмен SOAP; нельзя считать, что любой из них переписывает или перехватывает все загрузки schema во время создания.