에러블로그

cloudflare를 접해봤다.

워낙 잘되어있고 성능향상이나 서버ip감추기, 서버 성능 영향없는 ssl 적용 등 좋지만

이를 위해 http proxy(cdn)을 활성화 시키고 나면, 클라우드플레어 서버를 거쳐 오기 때문에

서버에 남는 사용자의 접속ip가 실제사용자 ip가 아닌 클라우드플레어 ip로 제공되는 바람에

기존 프로그램들이 말썽을 일으키는 경우가 많다.

특히 flexible/full/strict ssl은 클라우드플레어를 신뢰하지 않는다면 사용할 수 없는 기능.

여러 도메인을 모두 인증해주는 ECC 도메인 인증서기 때문에 인증서의 발급대상이 XXX.cloudflaressl.com 이다.

flexible/full/strict 관계 없이 모두 같다.

full/strict 을 사용하여도 서버와 클라우드플레어간의 전송구간, 사용자와 클라우드플레어와의 전송구간 이 암호화 되는 것이지 클라우드플레어가 컨텐츠를 볼 수 없는 것이 아니다.

막그린 그림이고 flexible ssl 적용시에 대한 예시이지만 대충 뭐 저렇다.

ssl을 적용하지 않아도 http proxy(cdn)기능을 활성화 하면 모든 통신은 클라우드플레어가 캐싱한다.

이때 사진이나 js, css 같은 정적인 자료는 캐싱되기 때문에 서버의 성능향상이 이루어진다.

하지만 프록시를 사용할 경우 개념상 사용자가 서버에 접속한 게 아니라 위 그림처럼 클라우드플레어가 사용자 대신 받았다가 사용자에게 보내주는 것이기 때문에 서버관점에서 접속한 사용자는 클라우드플레어 이다.

PHP의 경우 $_SERVER['REMOTE_ADDR'] 에 클라우드플레어의 IP가 나타난다. JSP, ASP, node.js 가릴 것 없이 당연히 모두 마찬가지다.

클라우드플레어는 이러한 점을 보완하기 위해 CF_로 시작하는 확장변수들을 제공한다.

참고 : http://stackoverflow.com/questions/14985518/cloudflare-and-logging-visitor-ip-addresses-via-in-php

PHP의 경우 $_SERVER["HTTP_CF_CONNECTING_IP"] 를 사용하면 실제 IP를 얻을 수 있다.

하지만 xe 같은 범용 프로그램을 사용하는 경우 이것의 관리가 너무 불편하다.

nginx의 경우 이런 프록시서버를 통한 접속의 경우를 위해 real_ip 모듈이 제공된다.

ubuntu 14.04 lts를 기준으로 다음 설정을 /etc/nginx/conf.d/cloudflare_realip.conf 파일로 만들어 넣고

sudo nginx -s reload 명령 한번 내려 설정 리로딩시켜주면 이후에는 원 아이피가 REMOTE_ADDR 같은 환경 변수에 담겨오게 된다.

xe의 조회수, 카운터 같은 기능들은 전적으로 ip에 의존하기 때문에 프로그램을 고치거나 위 설정을 적용해서 해결이 가능하다.

혹시 서버가 haproxy같은 또 다른 프록시를 사용하고 있다면 해당 ip도 위 설정에 적어서 해결할 수 있다.

이때에는 real_ip_header가 CF-Connecting-IP가 아닌 X-Forwarded-For 같은 범용 헤더이거나 또 다른 전용헤더일 수 있으니 해당 헤더를 확인.