Fiddler не обнюхивает трафик SOAP с веб-сайта ASP.NET

До сих пор я успешно использовал fiddler для прослушивания трафика веб-сервисов как из тестовых устройств, так и из консольных приложений и веб-проектов.

Сегодня я заметил, что больше не могу обнюхивать такой трафик, если я запускаю свое веб-приложение (это веб-сайт ASP.NET, размещенный локально в IIS). Я вижу весь локальный трафик, но трафик веб-службы просто пропал (служба получает удар, поскольку я вижу отладку ответа в коде).

Я все еще могу успешно обнюхивать запросы и ответы мыла от тестовых устройств или консольных приложений в том же решении (в той же среде).

Если бы это было обновление безопасности Windows (я использую Win7) или подобное, оно бы никогда не сработало, я думаю (если только оно не влияет только на трафик, маршрутизируемый через IIS).

Что я должен искать, что могло бы вызвать такое поведение?

Любые указатели приветствуются!

ПРИМЕЧАНИЕ: Я вижу локальный трафик, но не вижу запросы / ответы SOAP веб-службе, которая в любом случае не размещается локально (это песочница, которую предоставляет другая команда).

РЕДАКТИРОВАТЬ: эта конфигурация сработала (см. в блоге Рика Страла)

  <system.net>
    <defaultProxy>
      <proxy
        usesystemdefault="False"
        bypassonlocal="True"
        proxyaddress="http://127.0.0.1:8888"/>
    </defaultProxy>
  </system.net>

person JohnIdol    schedule 06.05.2010    source источник
comment
Я только что заметил, что это, наверное, обман. stackoverflow.com/questions/1937805/   -  person kevindaub    schedule 07.05.2010
comment
обратите внимание на обман - я могу видеть локальный трафик, но не запросы / ответы SOAP на веб-службу, которая не размещена локально (это песочница, которую предоставляет другая команда)   -  person JohnIdol    schedule 07.05.2010


Ответы (6)


Что такое клиент веб-службы? ASP.NET?

Трафик ASP.NET не передается через прокси, если вы не настроили ASP.NET для использования прокси. Возможно / вероятно, что app.config или machine.config изменились так, что трафик больше не проксируется?

Вам следует взглянуть на этот раздел: http://www.fiddlerbook.com/fiddler/help/hookup.asp#Q-DOTNET

person EricLaw    schedule 07.05.2010
comment
@Eric: да, клиент - ASP.NET. Я могу видеть весь локальный трафик (включая вызовы локально размещенных веб-служб), за исключением вызовов служб на другие IP-адреса - это началось недавно. Если я запускаю тестовую оснастку, которая есть у меня в том же решении, я все равно могу видеть трафик запроса / ответа мыла на другую машину, которую я ищу. - person JohnIdol; 07.05.2010
comment
также - если прокси не был настроен должным образом, я не ожидал увидеть никакого трафика - person JohnIdol; 07.05.2010
comment
Вероятно, вам следует перейти на программное обеспечение безопасности, которое менее подвержено очевидным ложным срабатываниям. blogs.msdn.com/fiddler/archive/2010/05/08/ - person EricLaw; 08.05.2010
comment
@Eric, можете ли вы придумать какое-либо объяснение того, что я вижу локальный трафик, но я не вижу этих SOAP-запросов к внешнему компьютеру, но при работе вне веб-проекта ASP.NET я вижу их в порядке? - person JohnIdol; 09.05.2010
comment
Вы хотите сказать, что запросы вашего проекта ASP.NET на ресурсы на основе 127.0.0.1 отображаются в Fiddler, но запросы для ресурсов с других сайтов того же проекта НЕ видны? Это довольно странно (если, конечно, у вас не установлен фильтр, скрывающий такой трафик). Как вы отправляете рассматриваемые HTTP-запросы? - person EricLaw; 10.05.2010
comment
Я вижу трафик localhost из браузера в IIS (т.е. ПОЛУЧИТЬ localhost / mySite / MyStartPage.aspx 200 OK (текст / html)), но я не вижу трафика от IIS, обращающегося к удаленному серверу, на котором размещена веб-служба. Я отправляю запросы через конечные точки WCF, никак не фильтруя. Я могу видеть трафик, когда веб-сайт не запущен, но отправляемые данные создаются вручную, так как не создаются моим веб-приложением, что затрудняет устранение неполадок. Вот что я хотел бы видеть при запуске веб-сайта - ›POST XXX.XX .XXX.XXX: 9080 / WebServiceDomain / myService 500 OK (текст / xml) и т. Д. - person JohnIdol; 10.05.2010
comment
также еще одна вещь, которую я заметил, которая может помочь в устранении неполадок - если я вставлю URL-адрес конечной точки в браузер, он будет отображаться в трафике нормально. - person JohnIdol; 10.05.2010
comment
Правильно - это означает, что все, что у вас запущено на вашем сервере IIS (предположительно, приложение ASP.NET), не использует Fiddler в качестве прокси. Это неудивительно, потому что ASP.NET не будет связываться с Fiddler по умолчанию, если вы вручную не используете web.config или сам код, чтобы указать на экземпляр Fiddler. - person EricLaw; 11.05.2010
comment
На данный момент я вернулся к ведению журнала WCF, но не могли бы вы указать мне на любую связанную документацию для редактирования web.config для маршрутизации трафика через скрипач? я бы предпочел использовать скрипач, чем встроенное ведение журнала, что облом - person JohnIdol; 12.05.2010
comment
У меня есть это в этих настройках привязки WCF (bypassonlocal = false и usedefaultproxy = true), но до сих пор ни один из вызовов службы не фиксируется скрипачом - person JohnIdol; 21.05.2010
comment
@JohnIdol: логические значения не имеют значения для ASP.NET, потому что ASP.NET работает под другой учетной записью пользователя. Таким образом, UseDefaultProxy означает использование прокси по умолчанию для учетной записи пользователя ASP.NET. Но когда Fiddler запущен, это прокси по умолчанию для ВАШЕЙ учетной записи пользователя, а не для учетной записи ASP.NET. Вы должны явно установить свойство defaultproxy, чтобы оно указывало на 127.0.0.1:8888 - person EricLaw; 21.05.2010
comment
явная установка прокси (согласно редактированию) сделала свое дело - спасибо за помощь! - person JohnIdol; 21.05.2010

Если вы хотите просматривать http-трафик между вашим веб-сайтом и веб-службой на машине разработки и не хотите изменять свой machine.config.

Одно из простых решений - изменить идентификатор пула приложений вашего веб-сайта, чтобы использовать ваши собственные учетные данные текущего вошедшего в систему пользователя. Это означает, что ваш веб-сайт примет ваши настройки прокси-сервера и теперь будет перенаправлять на Fiddler.

person sjclark76    schedule 22.07.2014
comment
И как я могу это сделать? В моем IIS есть только эти параметры: LocalService, LocalSystem, NetworkService и ApplicationPoolIdentity. - person Harry Ninh; 29.06.2016
comment
- ›Пулы приложений -› Выберите пул приложений - ›Расширенные настройки -› Идентификация - ›Пользовательская учетная запись -› Введите свои учетные данные - person sjclark76; 12.07.2016

Убедитесь, что веб-служба, которую вы вызываете (из IE), не является http://localhost/yourwebservice.

Fiddler не будет перехватывать трафик localhost из IE, вместо этого используйте http://machinename/yourwebservice.

person Stephen Dolier    schedule 07.05.2010
comment
У меня есть IP: portNo / mywebservice - веб-сервис не размещен на моем локальном компьютере - person JohnIdol; 07.05.2010
comment
Не знал, что Fiddler не захватывает трафик Localhost. Большое спасибо. - person lidermin; 15.04.2013

Я столкнулся с этой проблемой около недели назад. Попробуйте эту страницу: http://docs.telerik.com/fiddler/Observe-Traffic/Troubleshooting/NoTrafficToLocalhost http://www.fiddler2.com/fiddler/help/hookup.asp#Q-LocalTraffic

У меня сработал ipv4.fiddler. Надеюсь это поможет.

person kevindaub    schedule 07.05.2010
comment
Я вижу локальный трафик, но не запросы / ответы SOAP, которые я ищу - веб-служба не размещена локально (это песочница, которую предоставляет другая команда, я получаю доступ через зеркало в локальной сети) - person JohnIdol; 07.05.2010

Вероятно, вы используете порт, отличный от 80 для этих HTTP-запросов. Я помню, как настраивал обратный прокси-сервер для просмотра запросов WCF, которые я делал на своем локальном компьютере во время разработки. Вот документация: http://www.fiddlertool.com/fiddler/help/reverseproxy.asp

person marr75    schedule 07.05.2010

Можете ли вы попробовать следующее -

  1. Попробуйте остановить брандмауэр Windows и посмотрите, что произойдет
  2. попробуйте использовать firefox и перенаправить трафик на скрипач и посмотреть, что произойдет
person Prashant    schedule 06.05.2010
comment
спасибо, уже пробовал firefox и chrome (он всегда работал с хромом, но когда он перестал работать, я попробовал с FF и IE) - без разницы. Завтра попробую еще раз с Win firewall, отключив его первым делом и доложу. - person JohnIdol; 07.05.2010
comment
Вы пытались остановить брандмауэр Windows? - person Prashant; 07.05.2010