Après le proxy nginx, comment obtenir l'adresse IP que l'utilisateur visite réellement et comment traiter le problème de nginx reporting 504 lors de l'accès à l'interface chronophage


avant-propos

1. Lorsque j'ai rencontré l'opération d'enregistrement des enregistrements d'accès des utilisateurs au travail, j'ai immédiatement pensé à enregistrer un article sur l'obtention de l'adresse IP réelle de l'utilisateur après le proxy nginx. 2. Lors de l'accès à l'interface
chronophage, nginx a signalé une erreur 504 et a enregistré le fonctionnement de nginx configurant le délai d'expiration de l'interface d'accès.


1. Obtenez l'adresse IP réelle de l'utilisateur après le proxy nginx

1.1. Contexte :

Dans les applications pratiques, nous pouvons avoir besoin d'obtenir l'adresse IP de l'utilisateur, comme porter un jugement sur la connexion à distance, ou compter le nombre de visites IP, etc. Habituellement, nous pouvons utiliser request.getRemoteAddr() pour obtenir l'adresse IP du client, mais lorsque nous utilisons Après avoir utilisé nginx comme proxy inverse, l'adresse IP du serveur nginx est toujours obtenue en utilisant request.getRemoteAddr().

1.2 Solutions

Une requête peut certainement être divisée en un en-tête de requête et un corps de requête, et les informations d'adresse IP de notre client sont généralement stockées dans l'en-tête de requête. Si votre serveur utilise Nginx pour l'équilibrage de charge, vous devez configurer les en-têtes de requête X-Real-IP et X-Forwarded-For à votre emplacement.

location /api {
    
    
                limit_req zone=allipse burst=24000 nodelay;
                add_header 'Access-Control-Allow-Origin' '*';
                add_header 'Access-Control-Allow-Credentials' 'true';
                add_header 'Access-Control-Allow-Headers' 'x-requested-with,content-type';
                proxy_pass http://api;
                proxy_set_header   Host    $host;
                proxy_set_header   Remote_Addr    $remote_addr;  
                proxy_set_header   X-Real-IP    $remote_addr;  //一层代理时是用户真实ip,二层代理时是第一台nginxip
                proxy_set_header   X-Forwarded-For    $proxy_add_x_forwarded_for;//一层代理时没有值,多层代理里面会存储多个ip值,第一个值就是真实用户ip
       }

1)proxy_set_header X-real-ip $remote_addr ;

Obtenez la véritable adresse IP de l'utilisateur côté serveur Web.

Cependant, en fait, il n'y a pas qu'une seule façon d'obtenir la véritable adresse IP de l'utilisateur, continuons à l'examiner ci-dessous.

2)proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for ;

Jetons un coup d'œil à la variable X-Forwarded-For ici, qui est une norme non-rfc développée par squid pour identifier l'adresse d'un client se connectant à un serveur Web via un proxy HTTP ou l'adresse IP d'origine de l'équilibreur de charge. -Pour est défini, il y aura un enregistrement chaque fois qu'il est transmis via le proxy.Le format est client1,
proxy1,
proxy2, et les adresses sont séparées par des virgules.Puisqu'il s'agit d'une norme non-rfc, il n'y a pas de valeur par défaut, et il doit être ajouté par défaut.Dans ce cas, la requête transmise par le proxy, du point de vue du backend, l'adresse distante est l'ip du côté proxy
. C'est-à-dire que, par défaut, nous ne pouvons pas obtenir l'adresse IP de l'utilisateur en utilisant request.getAttribute("X-Forwarded-For"), si nous voulons obtenir l'adresse IP de l'utilisateur via cette variable

1.3. Exemples

Il existe une application Web, transmise par deux nginx avant elle, www.linuxidc.com signifie que l'utilisateur accède au Web via deux nginx.

Dans le premier nginx, utilisez

proxy_set_header X-Forwarded-For$proxy_add_x_forwarded_for ;

L' erreur d'analyse KaTeX actuelle : double indice à la position 12 : proxy_add_x_̲forwarded_for variable... remote_addr, et la valeur de $remote_addr est l'adresse IP de l'utilisateur, donc après affectation, la valeur de la variable X-Forwarded-For est la véritable adresse IP de l'utilisateur .

Au deuxième nginx, utilisez

proxy_set_header X-Forwarded-For$proxy_add_x_forwarded_for ;

L'erreur d'analyse KaTeX actuelle : Double indice à la position 12 : variable proxy_add_x_̲forwarded_for... La valeur de la partie remote_addr est l'adresse IP du nginx précédent, donc après cette affectation, la valeur du X-Forwarded-For actuel devient "l'utilisateur vraie ip, l'ip du premier nginx", donc ce sera clair.

Enfin, nous voyons qu'il y a une autre erreur d'analyse KaTeX : Double indice à la position 7 : http_x_̲forwarded_for variable... http_x_forwarded_for trouvera que la valeur obtenue en utilisant request.getAttribute("X-Forwarded-For") côté serveur Web est nul. Si vous souhaitez obtenir l'adresse IP de l'utilisateur via request.getAttribute("X-Forwarded-For"), vous devez d'abord utiliser proxy_set_header X-Forwarded-For$proxy_add_x_forwarded_for ; afin que vous puissiez obtenir la véritable adresse IP de l'utilisateur.

1.4. Résumé

Stockage : configurez l'en-tête de requête suivant proxy_set_header X-Real-IP $remote_addr dans le bloc d'emplacement de nginx
 ;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for ;

Récupération : dans le backend via request.getHeader("X-Real-IP ''), request.getHeader("X-Forwarded-For '')

Conclusion: l'ip réelle de l'utilisateur peut être obtenue par configuration X-Real-IP au premier niveau de proxy, le premier nginxip est au deuxième niveau de proxy, il n'y a pas de valeur au premier niveau de proxy, plusieurs valeurs d'ip sera stocké dans le proxy multicouche, la deuxième valeur One est l'adresse IP réelle de l'utilisateur, alors vous devez utiliser X-Forwarded-For

2. Accéder à l'interface fastidieuse nginx signale l'erreur 504

2.1, la cause du problème

nginx响应超时,页面出现504 gateway time-out

Ce genre de situation se produit souvent lorsque nginx est utilisé comme proxy inverse. Par exemple, lorsque nginx est utilisé comme proxy inverse pour transférer une certaine interface swagger, lorsqu'une erreur est signalée lors de l'accès à l'interface, le code d'état est généralement 504, qui est le problème du délai d'expiration du proxy. Une interface lente a dépassé le délai d'expiration par défaut de notre accès à l'interface nginx.

2.2 Solutions

Mode proxy
Généralement, nous utilisons le mécanisme de proxy de nginx comme proxy inverse. À ce stade, nous devons modifier le fichier de configuration nginx nginx.conf et ajouter le contenu suivant dans la section http ou serveur :

large_client_header_buffers 4 16k;
client_max_body_size 30m;
client_body_buffer_size 128k;

proxy_connect_timeout 90; #后端服务器连接的超时时间,发起握手等候响应超时时间
proxy_send_timeout 90;  #后端服务器数据回传时间,就是在规定时间内后端服务器必须传完所有的数据
proxy_read_timeout 90;  #连接成功后,等候后端服务器响应时间,其实已经进入后端的排队之中等候处理(也可以说是后端服务器处理请求的时间,页面等待服务器响应时间)
proxy_buffers 4 32k;  #4是数量 32k是大小 该指令设置缓存区的大小和数量,从被代理的后端服务器取得的第一部分响应内容,会放置到这里,默认情况下,一个缓存区的大小等于内存页面大小,可能是4k也可能是8k取决于平台
proxy_busy_buffers_size 64k; #nginx在收到服务器数据后,会分配一部分缓冲区来用于向客户端发送数据,这个缓存区大小由proxy_busy_buffers_size决定的。大小通常是proxy_buffers单位大小的两倍,官网默认是8k/16k

proxy_temp_file_write_size 64k;

Ensuite, redémarrez nginx et le problème général de délai d'attente sera résolu.

Méthode fastcgi
Dans la plupart des cas, nous utilisons la méthode proxy, mais parfois nous rencontrons également la méthode fastcgi, comme la scène de l'utilisation de nginx pour traiter des pages php. En fait, la méthode de traitement est similaire, il s'agit également de modifier le fichier de configuration nginx nginx.conf, et d'ajouter le contenu suivant dans la section http ou serveur :

large_client_header_buffers 4 16k;
client_max_body_size 30m;
client_body_buffer_size 128k;
fastcgi_connect_timeout 600 :指定连接到后端FastCGI的超时时间。
fastcgi_send_timeout 600 :向FastCGI传送请求的超时时间。
fastcgi_read_timeout 600 :指定接收FastCGI应答的超时时间。
fastcgi_buffer_size 64k :指定读取FastCGI应答第一部分需要用多大的缓冲区,默认的缓冲区大小为。fastcgi_buffers指令中的每块大小,可以将这个值设置更小。
fastcgi_buffers 4 64k :指定本地需要用多少和多大的缓冲区来缓冲FastCGI的应答请求,如果一个php脚本所产生的页面大小为256KB,那么会分配4个64KB的缓冲区来缓存,如果页面大小大于256KB,那么大于256KB的部分会缓存到fastcgi_temp_path指定的路径中,但是这并不是好方法,因为内存中的数据处理速度要快于磁盘。一般这个值应该为站点中php脚本所产生的页面大小的中间值,如果站点大部分脚本所产生的页面大小为256KB,那么可以把这个值设置为“8 32K”、“4 64k”等。
fastcgi_busy_buffers_size 128k :建议设置为fastcgi_buffers的两倍,繁忙时候的buffer。
fastcgi_temp_file_write_size 128k :在写入fastcgi_temp_path时将用多大的数据块,默认值是fastcgi_buffers的两倍,该数值设置小时若负载上来时可能报502BadGateway。

Ensuite, redémarrez nginx et le problème général de délai d'attente sera résolu.

exemple:
insérez la description de l'image ici

2.3 Conclusion

Ajoutez principalement la configuration suivante dans le bloc http ou le bloc de serveur proxy spécifique pour augmenter le délai de réponse de l'interface

proxy_connect_timeout 90 ; #Le délai d'expiration de la connexion au serveur principal, initier la poignée de main et attendre le délai d'expiration de la réponse
proxy_send_timeout 90 ; #Temps de retour des données du serveur principal, c'est-à-dire que le serveur principal doit transmettre toutes les données dans le délai spécifié
proxy_read_timeout 90 ;

Je suppose que tu aimes

Origine blog.csdn.net/wei1359765074410/article/details/127683608
conseillé
Classement