Як налаштувати проксі в Power BI

Якщо вам потрібно налаштувати проксі в Power BI, почніть із простої істини: цей посібник стосується Power BI Desktop у Windows, а не кожного продукту Microsoft із вікном входу. Це важливо, бо Power BI Desktop зазвичай підпорядковується мережевим правилам, заданим у Windows, і ви можете взагалі не знайти в самому застосунку окремий перемикач «proxy». Саме тому формулювання Power BI Desktop проксі Windows тут описує типову ситуацію, а не виняток. Одна хибна припущена деталь може коштувати вам пів дня.

Користуйтеся цим шляхом, якщо Power BI Desktop не може виконати вхід, не може під’єднатися до служби Power BI або зривається під час оновлення. Якщо проблема лише в одному джерелі даних, виправлення може бути в іншому місці. Якщо збій виникає ще до завантаження першого набору даних, підозра на проксі значно сильніша, і саме тоді потрібне точне налаштування проксі для Power BI.

1. Переконайтеся, яку саме програму Power BI ви використовуєте

Спершу підтвердьте, що ви працюєте саме з Power BI Desktop для Windows. Настільний застосунок, служба Power BI в браузері та локальний шлюз працюють по-різному і не мають одного спільного параметра проксі. Якщо ви в браузері, вам потрібно шукати налаштування проксі саме в браузері.

Цей посібник не охоплює мобільні застосунки Power BI або загальне налаштування проксі у Windows для всього комп’ютера. Також тут не йдеться про мережеву політику Microsoft 365 на рівні тенанта. Наша вузька задача проста: Power BI Desktop на ПК з Windows має отримати доступ через проксі для входу, оновлення або підключення до служби.

Саме така вузька рамка економить час. Дуже багато часу.

Перш ніж щось змінювати, відкрийте Power BI Desktop і зверніть увагу, у який саме момент виникає збій. Якщо помилка з’являється під час входу, це один сценарій. Якщо під час оновлення — інший. Якщо задіяний шлюз, це третій сценарій, і виправлення може бути взагалі не на вашому ноутбуці.

2. З’ясуйте точні параметри проксі, які потрібні вашій мережі

Вам потрібно більше, ніж просто «у нас є проксі». Потрібні ім’я хоста, порт, спосіб автентифікації та інформація, чи використовує компанія PAC-файл, чи ручну конфігурацію проксі. Без цих даних ви лише здогадуєтеся.

Попросіть назву хоста проксі у форматі, який очікує ваша мережева команда, наприклад DNS-ім’я або IP-адресу. Також запитайте номер порту. Якщо потрібна автентифікація, з’ясуйте, чи це базові облікові дані, доменний вхід, NTLM, Kerberos або щось інше. Одна ця деталь змінює все налаштування.

Деякі організації публікують PAC-файл і очікують, що Windows автоматично визначатиме проксі. Інші вимагають вручну вказати фіксований сервер проксі. Якщо ви не знаєте, який саме варіант у вас, спершу уточніть це в ІТ. Ручне налаштування в мережі, де працює лише PAC, часто дає збій так, ніби проблема саме в Power BI.

Для швидкого розуміння термінів сторінка термінологія VPN і проксі допоможе розмежувати мову про проксі та мову про VPN. У внутрішніх заявках ці поняття часто плутають, і це створює зайву плутанину.

Запам’ятайте ще одну деталь: чи змінюється проксі залежно від мережі. Ноутбук удома, у Wi‑Fi та в офісній мережі може бачити різні правила проксі. Це має значення, коли звіт працює в понеділок і не працює у вівторок.

3. Перевірте, куди саме Power BI намагається вийти в інтернет

Power BI Desktop робить не один мережевий запит. Є вхід у Microsoft, є доступ до служби Power BI, є взаємодія зі шлюзом, і кожне джерело даних може додавати ще більше запитів. Проксі може блокувати один маршрут і не зачіпати інші.

Почніть із входу. Якщо Power BI Desktop не може автентифікуватися у ваш обліковий запис Microsoft або робочий обліковий запис, проксі може блокувати кінцеві точки Microsoft. Потім перевірте доступ до самої служби Power BI. Далі подивіться на джерело даних: SQL Server, SharePoint, веб-API або файли, що зберігаються за корпоративною мережею.

Окремої перевірки заслуговує зв’язок зі шлюзом. Особистому або корпоративному шлюзу може знадобитися окремий мережевий доступ, особливо якщо сам шлюз працює на іншому комп’ютері. Якщо настільний застосунок працює, але заплановане оновлення згодом не виконується, проксі може бути не єдиним чинником.

Корисне запитання таке: який саме зв’язок ламається першим? Саме перший збій зазвичай вказує на важливий рівень. Це простіше, ніж дивитися на фінальне повідомлення про помилку й сподіватися, що воно розповість усю історію. Зазвичай не розповідає.

Для планування мережевих підключень і портів проксі дивіться номери портів проксі для веб-скрапінгу. Контекст інший, але базова думка та сама: номер порту має таке ж значення, як і ім’я хоста.

4. Налаштуйте проксі на рівні Windows для Power BI Desktop

Найпоширеніший варіант — налаштувати проксі в Windows, щоб Power BI Desktop успадкував ці параметри. Зазвичай Power BI Desktop не пропонує окремої панелі керування проксі для звичайної настільної роботи. Тобто результат часто визначають саме мережеві параметри Windows.

Відкрийте параметри проксі у Windows і перевірте, чи ваша компанія використовує автоматичне чи ручне налаштування. Якщо у вас PAC-файл, введіть адресу скрипта, яку надав ІТ-відділ. Якщо у вас ручний проксі, введіть сервер і порт точно так, як вам їх повідомили. Одна помилка в порті може зупинити все.

Не вгадуйте правила винятків. Якщо мережева команда каже, що локальні адреси або певні домени Microsoft мають обходити проксі, внесіть ці винятки точно. Проксі, який перехоплює внутрішній трафік, може зламати трафік шлюзу або доступ до локального джерела даних. Це поширений збій, який здається випадковим, доки ви не звірите список винятків.

Якщо у вашому середовищі використовується ширший план безпеки, стаття як обрати VPN доречна лише як орієнтир для порівняння. VPN і проксі — це не одне й те саме, і VPN не замінює правило проксі для Power BI Desktop.

Після зміни параметрів проксі в Windows перезапустіть Power BI Desktop. А якщо це вимагає політика ІТ, перезапустіть і сам Windows. Деякі зміни проксі повністю застосовуються лише після перезавантаження мережевого стека. Цей невеликий крок економить багато хибних перевірок.

5. Обробіть автентифікацію проксі та запити на введення облікових даних

Якщо проксі вимагає ім’я користувача й пароль, Power BI Desktop може запитати їх під час входу, оновлення або першого підключення до джерела даних. Запит може надійти з Windows, із браузерного потоку входу Microsoft або безпосередньо з джерела даних. Екран виглядає схоже. Причина не завжди однакова.

Якщо ваша організація використовує інтегровану автентифікацію, проксі може приймати облікові дані вашої сесії Windows. У такому разі важливо, під яким обліковим записом ви ввійшли у Windows.

Звертайте увагу на повторні запити. Один запит у деяких конфігураціях є нормальним. Повторні запити зазвичай означають одне з трьох: облікові дані неправильні, проксі не приймає цей метод автентифікації або Power BI Desktop виходить на іншу кінцеву точку, яка потребує окремого правила. Це втомлює, але корисно.

Якщо вам потрібна глибша модель роботи автентифікованого проксі, посібник із кращих практик автентифікації проксі дає потрібний контекст. Він особливо корисний, коли компанія поєднує браузерний вхід, вхід у Windows і проксі-облікові дані в одному робочому процесі.

Є одна практична звичка: не зберігайте неправильні облікові дані й не повторюйте спроби безкінечно. Після трьох невдалих спроб зупиніться й уточніть метод проксі в ІТ. Заблоковані облікові записи нікому не допоможуть, а ще вони можуть зробити проблему з проксі гіршою, ніж вона є насправді.

6. Перевірте, чи Power BI може входити й завантажувати дані через проксі

Перевіряйте налаштування у три кроки. Спершу відкрийте Power BI Desktop і виконайте вхід. Потім підключіться до простого джерела, яке добре знаєте. Після цього оновіть невеликий набір даних або тестовий запит. Тримайте тест маленьким, щоб було зрозуміло, на якому кроці виникає збій.

Успішний вхід сам по собі ще не означає, що все працює. Power BI може увійти, але все одно зламатися, коли дістанеться до вебджерела даних або з’єднання зі службою. Панель може виглядати справною, а оновлення — ламатися у фоні. Саме тому справжній тест із даними має значення.

Якщо ви використовуєте вебджерела або автоматизоване отримання даних в інших інструментах, стаття про ротацію проксі для веб-скрапінгу пояснює, чому повторні запити можуть викликати різну поведінку. Power BI, звісно, не скрапить веб, але повторні звернення до джерела все одно можуть упиратися в правила проксі, ліміти облікових даних або фільтри кінцевої точки.

Перевірте точний текст помилки. Попередження про сертифікат — це не те саме, що збій автентифікації. Тайм-аут — це не те саме, що відхилене з’єднання. Якщо ви можете зберегти повідомлення та час, ІТ зможе звірити це з журналами проксі. Без цих даних їм теж доведеться гадати.

Якщо підключення працює в одній мережі й не працює в іншій, занотуйте різницю. Офісний Wi‑Fi, домашній Wi‑Fi та сеанси через VPN часто поводяться по-різному. Три тести кращі за один.

7. Усуньте типові точки відмови проксі в Power BI

Блокування кінцевих точок Microsoft — поширена проблема. Power BI Desktop може потребувати доступу до кількох служб Microsoft, а суворий проксі або брандмауер може заблокувати лише одну з них. Якщо вхід не працює, але вебсерфінг працює, не поспішайте вважати, що з проксі все гаразд. Вебперегляд і Power BI — не одне й те саме.

Огляд сертифікатів теж може створювати проблеми. Деякі засоби безпеки перевіряють HTTPS-трафік і підставляють власні сертифікати. Якщо Power BI Desktop або пов’язаний компонент Microsoft не довіряє цьому ланцюгу сертифікатів, з’єднання може обірватися. Зазвичай це виглядає як помилка безпечного з’єднання, а не як чітке повідомлення про проксі.

Проблеми зі шлюзом варто перевіряти окремо. Якщо машина зі шлюзом знаходиться в іншій підмережі, іншому офісі або іншому хмарному сегменті, їй може знадобитися власне правило проксі чи брандмауера. Зміна проксі на вашому ноутбуці не виправить шлюз, який не може вийти в інтернет зі своєї мережі. Просто, але легко пропустити.

Збої оновлення після зміни проксі часто спричиняють збережені облікові дані або старий шлях з’єднання. Спробуйте очистити облікові дані відповідного джерела даних у Power BI Desktop і ввести їх заново. Потім перевірте ще раз. Один застарілий набір облікових даних може продовжувати зривати роботу ще довго після того, як сам проксі вже налаштовано правильно.

Якщо вам потрібне ширше порівняння способів приховування мережі, стаття як приховати IP-адресу допоможе пояснити мережевій команді різницю між проксі, VPN і прямим підключенням до мережі. Така розмова зазвичай проходить краще, коли всі використовують одні й ті самі слова.

8. Зрозумійте, коли залучати ІТ або мережеву команду

Залучайте ІТ, коли політика проксі знаходиться поза вашим контролем. Якщо компанія використовує PAC-файл, списки дозволених адрес у брандмауері, перевірку сертифікатів або централізовану автентифікацію, імовірно, вам не дозволено виправляти це самостійно. Це не обмеження Power BI. Це питання мережевої політики.

Надайте їм чотири речі: точну версію Power BI Desktop, точний текст помилки, хост проксі або PAC-файл, який використовується, і час, коли виникла проблема. Чотирьох пунктів достатньо, щоб почати реальну перевірку. «Не працює» — недостатньо.

Якщо команда проксі запитає протокол джерела, вкажіть, чи збій стався під час входу, доступу до служби, зв’язку зі шлюзом або роботи з конкретним джерелом даних. Чим точніші ви будете, тим менше листування доведеться вести. Маленька деталь, великий ефект.

Бувають також випадки, коли проблема взагалі не в Power BI. Політика домену може блокувати потік входу Microsoft. Правило брандмауера може блокувати порт 443 до конкретної кінцевої точки. Політика сертифікатів може відхиляти інспекцію. Усе це — завдання для мережевої команди, а не для користувача настільного застосунку, який має здогадуватися.

Для компаній, які керують багатьма підключеними інструментами, стаття скільки коштують автентифіковані проксі може допомогти сформулювати бюджетну розмову, коли команда вирішує, чи вартий новий рівень проксі операційних витрат. Бюджетні обговорення рідко бувають приємними, але вони кращі за незрозумілі збої.

Якщо вашій організації потрібна чіткіша система визначень для внутрішніх заявок, тримайте під рукою статтю SOCKS5-проксі проти HTTP-проксі. Формулювання прості, а прості формулювання зменшують кількість поганих заявок. Погані заявки сповільнюють будь-яку зміну проксі.

І ще одна практична порада: збережіть примітку про робочу конфігурацію, щойно все запрацює. Запишіть режим проксі у Windows, розташування PAC-файлу або ім’я хоста ручного проксі, порт і дату зміни. Наступного місяця, коли щось знову зміниться, вам не доведеться починати з нуля.