Для яўнага ўліковага запісу проксі перадайце аб'ект уліковых даных у -ProxyCredential:

$proxyAccount = Get-Credential
Invoke-WebRequest -Uri https://example.com/ -Proxy http://proxy.example:8080 -ProxyCredential $proxyAccount

Замяніце адрас на дазволены сэрвіс. Get-Credential запытвае ўліковы запіс, а не ўбудоўвае пароль у камандны радок. Гэты запіс ідзе да пасярэдніка; даныя прызначэння — асобны параметр, і яны не могуць адказаць на 407 ад проксі.

Калі схема аўтэнтыфікацыі проксі і ідэнтычнасць працэсу падтрымліваюць інтэграваную аўтэнтыфікацыю, выберыце -ProxyUseDefaultCredentials. Не спалучайце яго з яўнымі данымі проксі ў тым жа запыце.

Праверце даведку для версіі PowerShell, якая выконвае скрыпт. Windows PowerShell і сучасны PowerShell адрозніваюцца рэалізацыяй і даступнасцю параметраў; падтрыманыя версіі таксама даюць -NoProxy для яўнага прамога запыту.

Калі той жа скрыпт паводзіць сябе інакш як заданне

Праверце адпаведныя запісы $PSDefaultParameterValues і канфігурацыю проксі, якую падтрымлівае працэс. Профіль можа дадаць пры запуску сеансу прадвызначаныя налады проксі для канкрэтнай каманды. Запланаванае заданне можа абыйсці гэты профіль і працаваць ад іншай ідэнтычнасці, нават калі файл скрыпта не змяніўся.

Параўнайце URL прызначэння, выбраны адрас, патрабаваны метад проксі, версію PowerShell і яўныя супраць прадвызначаных даных, хаваючы сакрэты. Калі аўтэнтыфікацыя проксі паспяховая, а прызначэнне вяртае 401, даследуйце ўваход на прызначэнні, а не пераносьце пароль проксі ў параметр даных крыніцы.

Падобныя артыкулы