部署檢查清單¶
網際網路是一個充滿敵意的環境。在部署您的 Django 專案之前，您應該花一些時間檢查您的設定，並考慮安全性、效能和操作。
Django 包含了許多安全功能。有些是內建的且永遠啟用。其他的則是可選的，因為它們並不總是適合，或者因為它們對於開發而言不方便。例如，強制使用 HTTPS 可能不適用於所有網站，而且對於本機開發來說是不切實際的。
效能最佳化是另一種在便利性上進行權衡的類別。例如，快取在生產環境中很有用，但在本機開發中就比較少用。錯誤報告的需求也差異很大。
以下檢查清單包含以下設定：
必須正確設定，Django 才能提供預期的安全等級；
預期在每個環境中都不同；
啟用可選的安全功能；
啟用效能最佳化；
提供錯誤報告。
這些設定中的許多設定都是敏感的，應該視為機密。如果您要發佈專案的原始碼，常見的做法是發佈適合開發的設定，並使用私有設定模組進行生產。
執行 manage.py check --deploy¶
可以使用 check --deploy 選項來自動化以下描述的一些檢查。請務必按照選項的文件中所述，針對您的生產設定檔執行它。
切換離開 manage.py runserver¶
runserver 命令並非為生產環境而設計。請務必切換到已準備好生產的 WSGI 或 ASGI 伺服器。如需一些常見選項，請參閱WSGI 伺服器 或 ASGI 伺服器。
重要設定¶
SECRET_KEY¶
密鑰必須是一個大的隨機值，而且必須保密。
請確保生產環境中使用的金鑰沒有在其他任何地方使用，並避免將其提交到原始碼控制。這會減少攻擊者取得金鑰的途徑。
請考慮從環境變數載入密鑰，而不是在您的設定模組中硬式編碼密鑰
import os
SECRET_KEY = os.environ["SECRET_KEY"]
或從檔案載入
with open("/etc/secret_key.txt") as f:
SECRET_KEY = f.read().strip()
如果輪換密鑰，您可以使用 SECRET_KEY_FALLBACKS
import os
SECRET_KEY = os.environ["CURRENT_SECRET_KEY"]
SECRET_KEY_FALLBACKS = [
os.environ["OLD_SECRET_KEY"],
]
請確保及時從 SECRET_KEY_FALLBACKS 中移除舊的密鑰。
DEBUG¶
您絕不能在生產環境中啟用偵錯。
您肯定正在使用 DEBUG = True 開發您的專案，因為這會啟用方便的功能，例如在您的瀏覽器中顯示完整的追蹤資訊。
但是，對於生產環境來說，這是一個非常糟糕的主意，因為它會洩漏有關您的專案的許多資訊：您的原始碼摘錄、區域變數、設定、使用的程式庫等等。
特定於環境的設定¶
ALLOWED_HOSTS¶
當 DEBUG = False 時，如果沒有適當的 ALLOWED_HOSTS 值，Django 就完全無法運作。
此設定是保護您的網站免受某些 CSRF 攻擊的必要設定。如果您使用萬用字元，您必須自行驗證 Host HTTP 標頭，或確保您沒有受到此類別攻擊的影響。
您也應該設定位於 Django 前面的網路伺服器來驗證主機。它應該回應靜態錯誤頁面，或忽略不正確主機的要求，而不是將請求轉發給 Django。這樣做可以避免在 Django 記錄中出現虛假的錯誤（或者如果您已設定錯誤報告，則會收到電子郵件）。例如，在 nginx 上，您可以設定預設伺服器以在無法辨識的主機上傳回「444 無回應」。
server {
listen 80 default_server;
return 444;
}
CACHES¶
如果您使用快取，則連線參數在開發和生產環境中可能不同。Django 預設為每個程序本機記憶體快取，這可能不理想。
快取伺服器通常具有弱式驗證。請確保它們只接受來自您的應用程式伺服器的連線。
DATABASES¶
資料庫連線參數在開發和生產環境中可能不同。
資料庫密碼非常敏感。您應該像保護 SECRET_KEY 一樣保護它們。
為了獲得最大的安全性，請確保資料庫伺服器僅接受來自您的應用程式伺服器的連線。
如果您沒有設定資料庫備份，請立即執行！
STATIC_ROOT 和 STATIC_URL¶
開發伺服器會自動提供靜態檔案。在生產環境中，您必須定義一個 STATIC_ROOT 目錄，其中 collectstatic 會複製這些檔案。
如需更多資訊，請參閱如何管理靜態檔案（例如圖片、JavaScript、CSS）。
MEDIA_ROOT 和 MEDIA_URL¶
媒體檔案是由您的使用者上傳的。它們是不可信任的！請確保您的網路伺服器絕不會嘗試解讀它們。例如，如果使用者上傳 .php 檔案，則網路伺服器不應執行它。
現在是檢查這些檔案備份策略的好時機。
HTTPS¶
任何允許使用者登入的網站都應該強制執行全網站 HTTPS，以避免以明碼傳輸存取權杖。在 Django 中，存取權杖包括登入/密碼、會話 Cookie 和密碼重設權杖。（如果您透過電子郵件傳送密碼重設權杖，則無法採取太多措施來保護它們。）
保護使用者帳戶或管理員等敏感區域是不夠的，因為 HTTP 和 HTTPS 使用相同的會話 Cookie。您的網路伺服器必須將所有 HTTP 流量重新導向至 HTTPS，並且只將 HTTPS 請求傳輸到 Django。
設定 HTTPS 後，請啟用下列設定。
效能最佳化¶
將 DEBUG = False 設定會停用僅在開發中有用的幾個功能。此外，您可以調整以下設定。
會話¶
考慮使用快取會話以提高效能。
如果使用以資料庫為基礎的會話，請定期清除舊會話，以避免儲存不必要的資料。
CONN_MAX_AGE¶
當連線到資料庫佔用大量請求處理時間時，啟用持續性資料庫連線可以帶來良好的速度提升。
這對於網路效能受限的虛擬化主機非常有幫助。
TEMPLATES¶
啟用快取範本載入器通常可以大幅提升效能，因為它可以避免每次需要渲染時都編譯範本。當 DEBUG = False 時，快取範本載入器會自動啟用。請參閱 django.template.loaders.cached.Loader 以取得更多資訊。
錯誤回報¶
當您將程式碼推送至生產環境時，希望它已經非常穩定，但您無法排除意外錯誤。幸運的是，Django 可以捕獲錯誤並相應地通知您。
LOGGING¶
在將您的網站投入生產環境之前，請檢查您的日誌設定，並在收到一些流量後，檢查它是否如預期般運作。
有關日誌記錄的詳細資訊，請參閱 日誌記錄。
ADMINS 和 MANAGERS¶
ADMINS 將會收到 500 錯誤的電子郵件通知。
MANAGERS 將會收到 404 錯誤的通知。IGNORABLE_404_URLS 可以幫助過濾掉虛假的報告。
有關透過電子郵件回報錯誤的詳細資訊，請參閱 如何管理錯誤回報。
透過電子郵件回報錯誤的擴展性不佳
在您的收件匣被報告淹沒之前，請考慮使用錯誤監控系統，例如 Sentry。Sentry 也可以聚合日誌。
自訂預設錯誤檢視¶
Django 包含了幾個 HTTP 錯誤代碼的預設檢視和範本。您可能想要覆寫預設範本，方法是在您的根範本目錄中建立以下範本：404.html、500.html、403.html 和 400.html。使用這些範本的預設錯誤檢視應該足以應付 99% 的 Web 應用程式，但您也可以自訂它們。
