[Fix] forward-headers-strategy: native를 framework로 수정

[changuii]

#️⃣ 이슈 번호

#72

🛠️ 작업 내용

forward-headers-strategy: native를 framework로 수정

• 현재, Swagger에서 Https임에도 불구하고, Http로 server가 잡히는 문제를 해결하기 위해 수정

Summary by CodeRabbit

릴리스 노트

• 설정 변경
  • 서버의 포워드된 헤더 처리 전략이 업데이트되었습니다. 이제 요청 처리 중 포워드된 헤더가 다른 방식으로 처리됩니다.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[gemini-code-assist]

Summary of Changes

Hello @changuii, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

이 PR은 Swagger 환경에서 HTTPS 연결이 HTTP로 잘못 인식되는 문제를 해결하기 위해 application.yml 파일의 server.forward-headers-strategy 설정을 조정합니다. native 전략 대신 framework 전략을 사용하여 올바른 프로토콜 인식을 보장하고, 개발 및 배포 환경에서 Swagger의 안정적인 동작을 지원합니다.

Highlights

• forward-headers-strategy 설정 변경: application.yml 파일에서 server.forward-headers-strategy 설정을 native에서 framework로 변경했습니다. 이 변경은 Swagger에서 HTTPS 연결임에도 불구하고 서버가 HTTP로 인식되는 문제를 해결하기 위함입니다.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[coderabbitai]

📝 Walkthrough

Walkthrough

application.yml 파일의 서버 설정에서 server.servlet.forward-headers-strategy 값을 native에서 framework로 변경했습니다. 이 설정은 프록시나 로드 밸런서를 통해 전달되는 X-Forwarded-* 헤더를 어느 계층에서 처리할지를 결정합니다. 네이티브 방식에서 프레임워크 기반 처리로 변경됨으로써 요청의 포워드 헤더 처리 메커니즘이 전환됩니다.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Possibly related issues

• [Fix] forward-headers-strategy를 framework로 변경 #72: 동일한 server.servlet.forward-headers-strategy 설정값을 native에서 framework로 변경하는 변경사항으로, 직접적으로 동일한 구성 조정을 다루고 있습니다.

---

💭 추가 검토 고려사항

이 변경은 매우 단순하지만, 프로덕션 환경에서는 미묘한 영향을 미칠 수 있는 부분입니다:

변경의 의미:

• native: 서블릿 컨테이너(Tomcat 등)에서 직접 포워드 헤더를 처리
• framework: Spring Boot가 포워드 헤더를 해석하여 요청 정보 재구성

확인이 필요한 부분:

• 로드 밸런서/프록시 환경에서 실제로 X-Forwarded-* 헤더가 전달되고 있는지
• 기존 native 방식에서 정상 작동했던 부분이 framework 방식에서도 동일하게 작동하는지
• 특히 HTTPS 리다이렉트, URL 생성 등이 올바르게 처리되는지 테스트 권장

가능하면 staging 환경에서 프록시/로드 밸런서를 거친 요청들이 제대로 처리되는지 검증 후 병합하시면 좋겠습니다.

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	PR 제목이 변경 사항의 핵심을 명확히 반영하고 있습니다. forward-headers-strategy를 native에서 framework로 수정하는 구체적인 변경 내용을 직관적으로 전달합니다.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[gemini-code-assist]

Code Review

안녕하세요. application.yml 파일에서 server.forward-headers-strategy 설정을 native에서 framework로 변경하신 내용을 확인했습니다. 리버스 프록시 환경에서 Swagger UI가 프로토콜을 잘못 인식하는 문제를 해결하기 위한 올바른 수정입니다. 이 변경으로 Spring 프레임워크 레벨에서 X-Forwarded-* 헤더를 처리하게 되어, 컨테이너에 독립적으로 동작하므로 더 안정적인 방법입니다. 좋은 수정입니다.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: f6be359df2

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Preserve X-Forwarded-For for logging

Switching server.forward-headers-strategy to framework registers Spring’s ForwardedHeaderFilter, which removes X-Forwarded-* headers from the request after adapting the remote address. Your LoggingFilter currently reads request.getHeader("X-Forwarded-For"), so once this change is active that header will be stripped and the logged ipAddress will become null for proxied requests. This is a regression for production logs when the app is behind a reverse proxy/load balancer; consider reading request.getRemoteAddr() post-filter or configuring the filter to keep the header if you still need it.

Useful? React with 👍 / 👎.

[github-actions]

Overall Project	93.41%	🍏

There is no coverage information present for the Files changed

[sonarqubecloud]

Quality Gate passed

Issues
116 New issues
2 Accepted issues

Measures
0 Security Hotspots
93.1% Coverage on New Code
0.2% Duplication on New Code

See analysis details on SonarQube Cloud

[coderabbitai]

Actionable comments posted: 0

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

src/main/resources/application.yml (1)

1-6: 포워드 헤더 처리: 전략 선택 전에 프록시 신뢰 경계 확보 필수

현재 framework 전략은 Spring 레벨에서 X-Forwarded-* 헤더를 해석합니다. 이것 자체는 문제가 아니지만, 중요한 점은 포워드 헤더는 클라이언트가 위조할 수 있다는 것입니다. 이것은 native든 framework든 마찬가지입니다.

따라서 가장 먼저 확인할 사항은:

• 에지 프록시(LB, API Gateway 등)에서 인터넷 facing 쪽의 Forwarded/X-Forwarded-* 헤더를 모두 제거하고, 자신이 생성한 헤더만 앱으로 전달하는가?
• 앱이 프록시를 거쳐야만 접근 가능한가 (직접 접근 차단)?

이 두 가지가 확보되면, native와 framework 중 선택은 운영 선호도 차이입니다.

옵션 A (framework 유지, Spring 레벨 일관성)

• 장점: 컨테이너 종류에 관계없이 동일한 동작; Spring 생태계와 통일된 처리
• 단점: 프록시 설정 의존성이 명확해야 함

옵션 B (native 변경, 컨테이너 네이티브 처리)

• 장점: Tomcat/Jetty 자체의 RemoteIpValve 같은 기능 활용; 필터 체인 단순화 가능
• 단점: 컨테이너별로 신뢰 프록시 설정을 별도로 관리해야 함

옵션 C (프로파일 분리)

• prod: framework (프록시 뒤 확정)
• local/dev: none (직접 접근 환경)

장점: 로컬에서 스푸핑 오작동 방지
단점: 프로파일 관리 복잡도

핵심은 전략 선택이 아니라 프록시 설정입니다. 프록시 측 헤더 정제가 확보되었는지, 그리고 현재 framework 선택의 배경(예: Swagger HTTPS 인식 문제)이 무엇인지 먼저 정리하면, 전략 선택은 자동으로 따라올 겁니다.

[taek2222]

@coderabbitai 해당 속성 바꾸기 전과 후에 어떤식으로 동작하길래 HTTPS로 돌아가는거야? 이해할 수 없어. 알려줘.

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🌐 Web query:

Spring Boot forward-headers-strategy native vs framework difference

💡 Result:

server.forward-headers-strategy controls who interprets Forwarded / X-Forwarded-* headers (scheme/host/port/prefix/client IP) so Spring can generate correct redirects/links behind a reverse proxy.

• framework: Spring Boot enables Spring Framework’s forwarded-header support:

  • Servlet stack: registers ForwardedHeaderFilter
  • Reactive stack: uses ForwardedHeaderTransformer
    Use this when you want consistent, container-independent behavior inside the app. [1]

• native: Spring Boot enables the embedded web server’s native forwarded-header support (e.g., Tomcat/Jetty/Undertow features) to apply the forwarded headers at the container level. This can be preferable when you want to rely on (or tune) the container’s proxy features (for Tomcat, Boot exposes extra server.tomcat.remoteip.* settings). [1]

• Defaults: On supported cloud platforms (e.g., Cloud Foundry/Heroku/Kubernetes), Spring Boot defaults to native; otherwise it defaults to none (ignore forwarded headers). [1]

References:

• Spring Boot “How-to” guide on forwarded headers and the meaning/defaults of native vs framework. [1]
• Spring Boot API enum docs summarizing FRAMEWORK vs NATIVE. [2]

[1] https://docs.enterprise.spring.io/spring-boot/docs/3.2.18.2/reference/html/howto.html
[2] https://docs.spring.io/spring-boot/api/java/org/springframework/boot/autoconfigure/web/ServerProperties.ForwardHeadersStrategy.html

---

@taek2222, 정확한 동작 원리를 설명드리겠습니다.

문제 상황

이 프로젝트는 아마도 리버스 프록시(로드 밸런서, API Gateway, Nginx 등) 뒤에서 실행되고 있을 것입니다. 일반적인 구조는 다음과 같습니다:

클라이언트 --[HTTPS]--> 리버스 프록시 --[HTTP]--> Spring Boot 앱

리버스 프록시가 HTTPS 요청을 받아서 백엔드로 HTTP로 전달하면서, 원래 프로토콜 정보를 헤더로 전달합니다:

• X-Forwarded-Proto: https
• X-Forwarded-Host: example.com
• X-Forwarded-Port: 443

native vs framework의 차이

native 모드의 문제점

• 내장 웹 서버(Tomcat)의 네이티브 기능에 의존합니다
• Tomcat의 RemoteIpValve가 활성화되는데, 이는 추가 설정(server.tomcat.remoteip.*)이나 특정 조건이 맞아야 제대로 동작합니다
• 설정이 불완전하면 X-Forwarded-* 헤더를 무시하고, Spring Boot는 실제 수신한 프로토콜(HTTP)만 인식합니다

framework 모드의 해결 방식

• **Spring Framework의 ForwardedHeaderFilter**를 사용합니다
• 이 필터가 모든 요청을 가로채서 X-Forwarded-* 헤더를 무조건 해석합니다
• HttpServletRequest의 메서드들(getScheme(), getServerName(), getServerPort() 등)을 오버라이드하여, 원본 요청 정보가 아닌 프록시가 전달한 정보를 반환하도록 만듭니다

Swagger에서의 구체적 동작

Swagger UI는 API 문서를 렌더링할 때 서버 URL을 생성하기 위해 HttpServletRequest의 정보를 사용합니다:

native 모드 (문제 발생):

request.getScheme()     // → "http"  (실제 수신 프로토콜)
request.getServerPort() // → 8080    (실제 수신 포트)
// 결과: http://example.com:8080/swagger-ui.html

framework 모드 (문제 해결):

request.getScheme()     // → "https" (X-Forwarded-Proto에서 추출)
request.getServerPort() // → 443     (X-Forwarded-Port에서 추출)
// 결과: https://example.com/swagger-ui.html

결론

framework 모드는 컨테이너 독립적이고 일관된 방식으로 forwarded 헤더를 처리하기 때문에, 추가 설정 없이도 리버스 프록시 환경에서 안정적으로 동작합니다. 반면 native 모드는 Tomcat의 세부 설정에 의존하므로, 설정이 불완전하면 헤더를 제대로 해석하지 못해 Swagger가 HTTP로 인식하는 문제가 발생한 것입니다.

참고: Spring Boot 공식 문서에서도 프록시 뒤에서 실행할 때는 framework 모드 사용을 권장하고 있습니다.