연결하다 철도 엑셀, 구글 시트, AI 및 REST로

DATABASE_PUBLIC_URL이지 DATABASE_URL이 아닙니다.

이는 철도 연결이 실패하는 가장 흔한 원인이며, 가장 도움이 되지 않는 방식으로 실패합니다.

• Railway의 개인 호스트 이름은 .railway.internal로 끝나며 Railway 자체 네트워크 내에서만 확인됩니다. 다른 곳에서는 전혀 확인되지 않습니다.
• 해당 담당자는 철도청 외부에서 근무하므로 개인 주소로는 절대 연락이 닿지 않습니다. — 연결이 끊어지면 이유를 알려주지 않고 그냥 연결이 종료됩니다.
• 그래서 카드는 해당 요청을 즉시 거부하고 해결 방법을 제시합니다. 바로 DATABASE_PUBLIC_URL에 있는 공용 TCP 프록시 호스트를 사용하는 것입니다. 이렇게 하면 조용한 타임아웃 메시지가 사용자가 조치를 취할 수 있는 메시지로 바뀝니다.
• 공용 프록시 호스트는 .proxy.rlwy.net으로 끝납니다. 이전 Railway 배포 환경에서는 .railway.app 호스트 이름이 사용되었으며, 서비스에서 해당 호스트 이름을 사용하는 경우 여전히 작동합니다.

포트 번호는 서비스별로 지정되므로 누구도 추측할 수 없습니다.

대부분의 관리형 Postgres 서비스는 5432 포트로 응답합니다. 하지만 Railway의 프록시는 그렇지 않으며, 카드에는 의도적으로 해당 필드가 비어 있습니다.

• 철도 회사는 서비스별로 프록시 포트를 할당합니다. 동일한 프로젝트 내의 두 데이터베이스는 서로 다른 프록시 포트를 가지며, 둘 다 5432 포트를 사용하지 않습니다.
• 포트 필드에 기본값이 없는 이유는 바로 그 때문입니다. 5432로 잘못 입력되면 연결이 실패할 수 있는데, 이는 포트 필드가 비어있는 것보다 더 심각한 문제입니다.
• DATABASE_PUBLIC_URL을 붙여넣으면 포트 번호도 다른 모든 정보와 함께 채워지므로, 일반적인 경로를 사용할 때는 포트 번호를 따로 찾을 필요가 없습니다.
• 필드를 직접 입력하는 경우, 포트 번호를 주의 깊게 복사해야 합니다. — 이는 오류가 발생할 가능성이 가장 높고, 실패하더라도 가장 적은 정보를 제공하는 분야입니다.

자체 서명 인증서와 여기서 암호화의 의미는 무엇일까요?

Railway의 Postgres 이미지는 자체 서명된 인증서를 제공하며, 이 인증서가 에이전트가 TLS를 처리하는 방식을 결정합니다.

• SSL 사용이 기본적으로 활성화되어 있으며 연결이 암호화됩니다. 에이전트는 단순히 TLS를 제공하는 것이 아니라 TLS를 요구합니다.
• 인증서 체인이 검증되지 않았습니다. 전체 검증을 수행하면 Railway의 자체 서명 인증서가 거부되므로, 체인 검증 없이 암호화만 요구하는 설정이 실제로 서비스에 적합한 설정입니다.
• 그건 목적지에 도착했다는 증거라기보다는, 도중에 누군가가 교통 정보를 읽는 것을 막기 위한 보호 장치로 이해하시면 됩니다.
• Railway Postgres 앞에는 풀러가 없으며 카드도 그렇지 않은 척하지 않습니다. — 이는 프록시를 통한 직접 연결이며, 풀링 모드를 선택할 수 없습니다.

-- 일반 Postgres, 읽기 전용, 공용 프록시를 통한 SELECT c.name, COUNT(o.id) AS orders, SUM(o.amount) AS revenue FROM public.customers AS c JOIN public.orders AS o ON o.customer_id = c.id WHERE o.placed_at >= now() - interval '30 days' GROUP BY c.name ORDER BY revenue DESC;