Wiki допомога: Як налаштувати домен для localhost і перевірити ліцензію модуля

Щоб відкрити локальний сайт за доменним ім’ям, додайте відповідність імені та IP-адреси у файл hosts і налаштуйте VirtualHost вебсервера. Але локальний домен сам по собі не активує ліцензію модуля. Можливість використання тестової копії та спосіб її активації потрібно уточнити для конкретного продукту.

Нижче — приклад для Apache 2.4, установленого безпосередньо на вашому комп’ютері, та адреси http://project.test. Для Docker, WSL, віртуальної машини або іншого вебсервера мережеві налаштування відрізнятимуться.

Localhost, локальний домен і ліцензія: у чому різниця?

Практичний порядок перевірки: спочатку переконайтеся, що відкривається потрібна локальна копія, а потім перевіряйте повідомлення модуля про активацію.

Чи потрібна окрема ліцензія для localhost або тестового домену?

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

Перед налаштуванням уточніть у постачальника:

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

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

Який домен вибрати для локального сайту?

Для прикладу використаємо project.test. Зона .test зарезервована для тестування в RFC 2606. Ім’я потрібно налаштувати локально: сама назва project.test не запускає сервер.

Не використовуйте випадковий домен у реальній зоні на кшталт .site: він може належати іншому власнику. Не підмінюйте адресу робочого магазину без конкретної потреби — так легше переплутати тестове й бойове середовища.

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

Крок 1. Додайте локальний домен у hosts

Збережіть копію файлу перед редагуванням. Відкрийте його з правами адміністратора, не видаляючи наявні записи.

На Windows системний каталог може відрізнятися; відповідний шлях — %WinDir%System32driversetchosts. Призначення файлу описано в довідці Microsoft.

Додайте рядок:

127.0.0.1 project.test

У hosts вказують тільки IP та ім’я: без http://, номера порту та шляху до сторінки. Збережіть файл саме як hosts, без розширення .txt.

Ця зміна діє на комп’ютері, де відредаговано файл. На іншому ноутбуці або всередині контейнера потрібні власні налаштування.

Крок 2. Налаштуйте VirtualHost для Apache 2.4

Знайдіть активну конфігурацію Apache. У різних збірках це може бути httpd.conf, підключений файл із віртуальними хостами або каталог sites-available. Важливо, щоб створений файл справді підключався до конфігурації сервера.

Приклад для локального каталогу /var/www/project/public:

<VirtualHost 127.0.0.1:80>     ServerName project.test     DocumentRoot "/var/www/project/public"      <Directory "/var/www/project/public">         Options -Indexes         AllowOverride None         Require local     </Directory> </VirtualHost>

Замініть обидва шляхи на фактичний публічний каталог вашого сайту. На Windows це може бути C:/sites/project/public. Каталог public є не в кожному проєкті: вказуйте той, де розташована точка входу сайту.

ServerName визначає ім’я, а DocumentRoot — каталог. Детальніше: іменні VirtualHost в Apache.

Require local призначений для локального доступу; правила описані в документації mod_authz_host. Цей приклад не призначений для публічного staging або доступу колег із мережі.

Перевірте Listen. VirtualHost не змушує Apache слухати порт. Для окремого локального екземпляра можна використовувати:

Listen 127.0.0.1:80

Не додавайте цей рядок поверх наявного Listen 80: спочатку перевірте активні директиви та усуньте перекриття. Зміна Listen впливає на весь екземпляр сервера, тому не застосовуйте її бездумно до конфігурації з іншими сайтами. Дивіться налаштування адрес і портів Apache.

Якщо сайт використовує .htaccess

У наведеному мінімальному прикладі AllowOverride None вимикає обробку .htaccess. Для CMS із правилами маршрутизації потрібно дозволити необхідні директиви або перенести їх у конфігурацію VirtualHost.

Для правил RewriteEngine / RewriteRule зазвичай потрібні mod_rewrite та дозвіл класу FileInfo. Якщо .htaccess містить інші директиви, перевірте їх окремо. Не замінюйте значення на All лише для того, щоб приховати помилку. Пояснення: як Apache обробляє .htaccess.

Не змішуйте старі Order allow,deny і Allow from all з сучасним Require: Apache не рекомендує таку конфігурацію. Джерело: перехід з Apache 2.2 на 2.4.

Крок 3. Перевірте конфігурацію та перезапустіть сервер

Використовуйте команди саме того Apache, який обслуговує ваш сайт.

Для Debian/Ubuntu з установленим пакетом Apache:

sudo apache2ctl configtest sudo apache2ctl -S

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

sudo systemctl restart apache2

На Windows, у каталозі з httpd.exe вашої збірки:

httpd.exe -t httpd.exe -S

Після успішної перевірки перезапустіть Apache через панель вашого локального середовища або його службу. Для macOS спосіб залежить від установленої збірки; systemctl не є універсальною командою для macOS.

Параметри -t і -S описані в офіційній довідці httpd.

Крок 4. Переконайтеся, що відкривається саме локальна копія

Відкрийте http://project.test і перевірте ознаку тестового середовища: наприклад, помітний напис «Локальна копія». Перед роботою з копією використовуйте окрему базу даних і вимкніть бойові завдання надсилання повідомлень, платежів та синхронізації.

Для перевірки HTTP-відповіді можна виконати:

curl -I http://project.test

Якщо потрібно перевірити VirtualHost незалежно від hosts:

curl --noproxy "*" --resolve project.test:80:127.0.0.1 -I http://project.test

У Windows PowerShell за потреби використовуйте curl.exe. Опція --resolve задає адресу лише для цього запиту, не змінюючи hosts; --noproxy виключає вплив проксі на тест. Дивіться довідку curl.

Не кожен застосунок підтримує HEAD-запити, які надсилає -I. Якщо отримали 405, перевірте звичайний GET без -I. Відповідь 200 сама по собі також не підтверджує активацію модуля.

Що робити, якщо локальний домен не працює?

Якщо бачите HTTP 500, перегляньте журнали вебсервера та застосунку. Це окремий діагностичний сценарій; дивіться що робити з помилкою 500.

Як увімкнути HTTPS для локального домену?

Запис у hosts не створює HTTPS. Потрібні сертифікат для project.test, довіра до нього на вашому комп’ютері та налаштований HTTPS-віртуальний хост.

Для розробки можна використати mkcert: він створює локально довірені сертифікати, але не налаштовує вебсервер замість вас. Приватний ключ локального центру сертифікації rootCA-key.pem не слід передавати іншим або додавати до репозиторію.

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

Чому webhook не приходить на localhost?

Для зовнішнього сервісу localhost означає його власне середовище, а не ваш комп’ютер. Локальний запис hosts на вашому ПК не робить адресу доступною для CRM, платіжного сервісу чи маркетплейсу.

Для вхідних запитів може знадобитися окреме тестове середовище з доступною HTTPS-адресою або налаштований тунель. Перевіряйте вимоги конкретного сервісу до callback URL, підпису запитів і тестового режиму.

Вихідний API-запит із локального сайту та вхідний webhook — різні напрямки обміну. Працездатність одного не підтверджує іншого. Базове пояснення: що таке API-інтеграція.

CiFrame допоможе перевірити локальну копію та роботу інтеграції

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

Для першого звернення надішліть:

• назву й версію CMS та модуля;
• операційну систему й локальне середовище;
• адресу, за якою відкриваєте копію;
• точний текст помилки або скриншот без секретних даних;
• бажаний результат: локальне тестування, staging або перенесення.

Напишіть на info@ciframe.com. Після уточнення завдання погодимо обсяг перевірки та наступні дії. Умови ліцензії стороннього продукту підтверджує його постачальник.

Перевірити моє тестове середовище

Часті запитання

Чи потрібно купувати домен для localhost?

Для локального імені project.test, налаштованого через hosts, публічна реєстрація не потрібна. Для зовнішнього тестового середовища вимоги залежать від способу його розміщення.

Чи достатньо змінити hosts, щоб модуль прийняв ліцензію?

Ні. Hosts змінює локальну відповідність імені та IP. Активація залежить від механізму та правил конкретного модуля.

Чи потрібно змінювати DNS робочого домену?

Для наведеного прикладу з project.test — ні. Зміни виконуються локально й не впливають на публічний DNS робочого сайту.

Чому localhost працює, а project.test — ні?

Перевірте hosts, ServerName і підключення VirtualHost. Працездатність стандартної сторінки localhost не означає, що сервер уже налаштований для іншого імені.

Що робити, якщо порт 80 зайнятий?

З’ясуйте, яка програма його використовує. Для локального сервера можна вибрати інший вільний порт, узгодити його в Listen та VirtualHost і відкривати сайт, наприклад, як http://project.test:8080. Порт не додають у hosts.

Чому приклад не працює в Docker або WSL?

Там сервер може працювати в іншому мережевому середовищі. Потрібно перевірити публікацію портів і адреси: 127.0.0.1 усередині контейнера не означає хост-комп’ютер. Наведений приклад розрахований на Apache безпосередньо на ПК.

Чи можна працювати повністю без інтернету?

Локальні файли й база можуть працювати без зовнішнього доступу, але активація ліцензії та інтеграції можуть потребувати інтернету. Це перевіряють окремо для кожного модуля й сервісу.