又一个@font-face问题：自定义字体本地正常FTP部署后异常

Alright, let's work through this problem step by step—since your custom font works locally in Visual Studio 2017 but breaks after uploading via FTP, the root cause is almost always related to file paths, server permissions, MIME types, or caching. Here’s how to diagnose and fix it:

• Verify font file upload and path accuracy
  First, confirm your .woff2 font file was actually uploaded to the correct directory relative to your .aspx page. For example, if locally your font lives in ./fonts/my-custom-font.woff2, make sure the fonts folder and file exist in the same relative location on the server.
  Test this directly by typing the full URL of the font file into your browser’s address bar—if you get a 404 error, the file is missing or the path is wrong.

• Check @font-face path in your CSS
  Open your browser’s developer tools (F12), go to the Network tab, and reload the page. Look for requests to your .woff2 file:

  • If it’s returning 404, double-check the src path in your @font-face rule. Absolute paths (like /fonts/my-custom-font.woff2) are more reliable than relative paths if your .aspx page is in a subdirectory.
  • Ensure the path matches exactly what’s on the server—capitalization matters on case-sensitive servers (like Linux-based hosts), so MyFont.woff2 vs myfont.woff2 will cause issues.

• Configure correct MIME types on the server
  Most web servers don’t recognize .woff2 files by default, which can lead to 403 Forbidden or 404 errors. You’ll need to add the MIME type for .woff2:

  • For IIS: Go to your site’s MIME Types settings, add a new entry with extension .woff2 and MIME type font/woff2.
  • For Apache: Add this line to your .htaccess file (or server config):

    AddType font/woff2 .woff2
    

  • For Nginx: Include this in your server block configuration:

    types {
      font/woff2 woff2;
    }
    

• Fix file permissions
  FTP uploads sometimes set incorrect file permissions that prevent the server from reading the font file. Use your FTP tool to set the font file’s permissions to 644 (read access for all users) and the parent folder to 755 (read/execute access for all). This ensures the server can serve the file to visitors.

• Clear browser cache
  Your local browser might be caching the working local font, so even after uploading the server version, it’s still using the old cached copy. Force a hard refresh with Ctrl+Shift+R (Windows/Linux) or Cmd+Shift+R (Mac), or test in incognito/private mode to bypass cache.

• Validate @font-face syntax
  Double-check your CSS rule for typos or missing details—here’s a correct example to reference:

  @font-face {
    font-family: 'MyCustomFont';
    src: url('/fonts/my-custom-font.woff2') format('woff2');
    font-weight: normal;
    font-style: normal;
    font-display: swap; /* Optional but improves performance */
  }
  

  Make sure format('woff2') is included, as some browsers rely on this to identify the font type.

• Check for server-side URL rewriting
  If your server uses URL rewrite rules (like for clean URLs), it might be altering the font file’s request path. In the Network tab of developer tools, check if the font request is being redirected or rewritten to an incorrect URL. Adjust your rewrite rules to exclude font files if needed.

内容的提问来源于stack exchange，提问作者PeteH