PHP Xdebug multi php versions in the server , fixing xdebug.so: undefined symbol: zend_post_startup_cb

If you have many php versions in the server we might face Xdebug installing.
Firstly, I installed via manual as
install PECL, then install xdebug through pecl
As result, I got an error

xdebug.so: undefined symbol: zend_post_startup_cb

The default php version in the server is PHP 7.3 . I need to install Xdebug for PHP 7.2
I used those links
https://gist.github.com/amenk/29636622c60a420330a8b827d166f9cf
https://qna.habr.com/q/729423
https://xdebug.org/docs/install
The server is Debian. I installed php7.2-dev. We will use phpize and php-config from the package.
It is MATTER to use version as  phpize7.2 and php-config7.2
1) download
2) tar -xzf xdebug-2.9.6.tgz && cd xdebug-2.9.6
3) phpize7.2
4) ./configure --with-php-config=/usr/bin/php-config7.2
5) make
6) copy from modules folder to lib folder.
to check that lib folder via phpize7.2
7) add to available modules with 20 priority
PS: firstly, I used 10 priority and got error with IonCube. 20 priority helped
Then restart PHP service and enjoy

Nginx map $request_uri example

If I need to add http auth to special location I can use map

http block

map $request_uri $auth {
    /2.3.5/  "Authorization Required";
    default  "off";
}

server block

    auth_basic $auth;

    auth_basic_user_file /etc/nginx/.htpasswd;

Magento 500 error Premature end of script headers: index.php, Error parsing script headers, (22)Invalid argument

[Wed Apr 29 13:55:43.181652 2020] [proxy_fcgi:error] [pid 113977] [client 127.0.0.1:38830] Premature end of script headers: index.php, referer: https://domain.tld/us/catalogsearch/result/?q=jacket

[Wed Apr 29 13:55:43.181721 2020] [proxy_fcgi:error] [pid 113977] [client 127.0.0.1:38830] AH01070: Error parsing script headers, referer: https://domain.tld/us/catalogsearch/result/?q=jacket

[Wed Apr 29 13:55:43.181726 2020] [proxy_fcgi:error] [pid 113977] (22)Invalid argument: [client 127.0.0.1:38830] AH01075: Error dispatching request to : , referer: https://domain.tld/us/catalogsearch/result/?q=jacket

Issue https://github.com/magento/magento2/issues/7657
https://cloud.githubusercontent.com/assets/3441674/20826784/5002f712-b8a8-11e6-95cf-ab8d9d94e239.png

header X-Magento-Tags size more than header size limit

Magento rewrite 404 error with checkout

It was dev site with enabled basic auth
Access log displayed 404 error
There was an error in nginx error log
 is not found (2: No such file or directory)

Working Apache config was
<IfModule mod_rewrite.c>
    Options +FollowSymLinks
    RewriteEngine on
    RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
    RewriteCond %{REQUEST_METHOD} ^TRAC[EK]
    RewriteRule .* - [L,R=405]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_FILENAME} !-l
    RewriteRule .* index.php [L]
</IfModule>

I was moving to Nginx and got an error 404, because I only disabled auth with
location /onestepcheckout/ {
    auth_basic off; 
}
I had to add auth off for checkout, but I forgot about rewrite
try_files $uri/ $uri/ /index.php$is_args$args;
It was a reason.
Resolving error was

location / {     
    try_files $uri/ $uri/ /index.php$is_args$args;
}

location /onestepcheckout/ {
    auth_basic off;
    try_files $uri $uri/ /index.php$is_args$args;
}

# POST response
location /rest/ {
    auth_basic off;
    try_files $uri $uri/ /index.php$is_args$args;
}

Magento CORS error (Access-Control-Allow-Origin)

https://absolutecommerce.co.uk/blog/cors-in-magento-2

/etc/nginx/magento2-cors.conf
add_header 'Access-Control-Allow-Origin' '*' 'always'; 

if ($request_method = 'OPTIONS') { 

  add_header 'Access-Control-Allow-Origin' '*' 'always'; 

  add_header 'Access-Control-Allow-Headers' 'x-requested-with' 'always'; 

  add_header 'Access-Control-Max-Age' 86400 'always'; 

  add_header 'Content-Length' 0 'always'; return 204; 

}

location /static/ { 

  location ~* \.(ico|jpg|jpeg|png|gif|svg|js|css|swf|eot|ttf|otf|woff|woff2)$ { 

    add_header X-Frame-Options "SAMEORIGIN"; 

    include /etc/nginx/magento2-cors.conf; 

  } 

  location ~* \.(zip|gz|gzip|bz2|csv|xml)$ { 

    add_header X-Frame-Options "SAMEORIGIN"; 

    include /etc/nginx/magento2-cors.conf; 

  } 

  add_header X-Frame-Options "SAMEORIGIN"; 

  include /etc/nginx/magento2-cors.conf; 

}

explanation CORS:

https://qna.habr.com/q/596375

Header Access-Control-Allow-* - это заголовки ответа, их должен отправлять сервер в ответ на запрос. 

Если запрос OPTIONS (браузер шлет сам перед основным запросом для проверки прав), то сервер должен так же ответить этими заголовками, но со статусом 204 и без тела
с клиента должен быть только заголовок Origin (откуда пришел запрос), если клиент в браузере, то браузер сам его отправит (X-Requested-With кстати тоже сам отправит)
а эти:
"Access-Control-Allow-Origin": "*",
"Access-Control-Allow-Methods" : "GET,POST,PUT,DELETE,OPTIONS",
"Access-Control-Allow-Headers": "Content-Type, Access-Control-Allow-Headers, Authorization, X-Requested-With"
должны быть с сервера, притом из Access-Control-Allow-Headers можно смело убрать Access-Control-Allow-Headers и X-Requested-With (первый Вы и не должны отправлять, а второй разрешен по умолчанию)

Magento 2 Some links from staging home page redirect to the production site

Some links from staging home page redirect to the production site.
Analyzing...
It is home page, so, I have to check cms* tables.
I checked with

select title,content from cms_block where content like '%www.prod.com%';

and found three records
I modified them with  variable {{config path="web/secure/base_url"}} instead of prod domain.
It could be done via Admin Panel or via

Cleared FPC cache
UPDATE cms_block set content = REPLACE(content, 'https://www.prod.com/', '{{config path="web/secure/base_url"}}') WHERE content LIKE '%https://www.prod.com/%';

Siege Load-testing

Siege command line:

siege -f links.csv -c 150 -t15m -d 7 -iv -m "Company1 Mar 31 2020" -l

-c - concurrent users
-t15m - test time
-d 7 - 7sec delay for each user
-i - INTERNET user simulation, hits URLs randomly
-m - MARK, mark the log file with a string
-l - log file, if it isn't specified, then default is used: /var/siege.log

I'm increasing concurrent users number with step 50 within each test.

Tips&tricks:

I got unexpected good results with higher concurrent users number after previous bad with lower ones.
The reason were FPC cache (redis in my case) and OpCache.
So, tricks are cleaning FPC and OpCache caches before each test.
In my case,
redis-cli -p 6380 FLUSHALL 
and restarting php